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PREFACE 


Objective 

The primary objective of this study is to define Image Processing 
System (IPS) requirements and configurations for the NASA sponsored 
advanced technology Earth Observatory System (EOS) . 

Scope 

The scope included investigation and definition of IPS operational, 
functional, and product requirements considering overall system constraints 
and interfaces (sensor, etc.)* The scope also included investigation of 
the technical feasibility and definition of a point design reflecting 
system requirements. The design phase required a survey of present and 
projected technology related to general and special-purpose processors, 
high-density digital tape recorders, and image recorders. 

Conclusions and Recommendations 

Major conclusions and recommendations include: 

(1) Digital image processing systems are feasible. The 

recommended configuration consists of a general-purpose 
digital computer augmented with special-purpose digital 
hardware, an input digital tape recorder and interfacing 
device, high-density digital tape recorders as the prr.mary 
output devices, and a laser beam film recorder interfaced to 
high-density digital tape recorders for film imagery generation. 

(1) Digital tape recorders with input rat^« high enough to accom- 
modate the EOS satellite transfer rate are not yet commercially 
available. However given present technology, they are 
feasible with minimum development cost. 

(3) The recommended primary archive is corrected data on high- 

density digital tape. This data may be copied for distribution 
as a product and used as input to reproduction units. These 
modular reproduction units give needed growth and flexibility. 
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(A) 


Data transfer (interfacing), working data storage, and data 
flow and control (operational timeline) are critical areas 
which will determine the success of a specific design. 

(5) Efficient means for identifying ground control points in the 
data must be determined to minimize data reprocessing compat- 
ible with required accuracies and data availability. 
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INTRODUCTION 


1.1 Background 

NASA’s Earth Observatory System (EOS) program is intended to develop 
and demonstrate advanced remote sensing techniques for management of tor- 
earth 1 s resources. The system will acquire high-resolution multispectral 
data of the earth’s surface which is transmitted to data processing centers 
for correction and reduction into images or digital tapes of unprecedented 
quality and variety to fulfill the varied requirements of investigators 
and user agencies. 

The overall EOS . ’stem includes: 

1. An Operations Control Center (OCC) which is the focal point 
of mission orbital operations 

2. The satellite itself which carries a payload that includes 
advanced multispectral sensors, telemetry, tracking and 
command subsystems, etc. 

3. A communications network linked to ground receiving sites 
that collect the multispectral data 

4. Ground image processing systems (IPS) for lata correction 
and redaction 

This study focuses on the IPS. Specifically, it investigates and 
defines IPS requirements and system configurations for facilities that 
employ all-digital image processing techniques for the correction of 
radicmetric errors and geometric distortions in the sensor images. 

The study was conducted over a period of three months during which 
numerous meetings and personal contacts were made with related technology 
groups within the NASA Goddard Space Flight Center EOS Project Office 
as well as industry. These groups included: design and operating personnel 

associated with the p c sent operational ERTS-1 system at Goddard; 
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technology groups involved in the overall EOS study effort in and outside 
of Goddard; and companies nroducing general- and special-purpose processors, 
digital tape recorders and imrge recorders, 

1.2 SUMMARY AND RECOMMENDATIONS 

Section 2 discusses the major system requirements and assumptions 
that form the basis of the IPS design approaches. This includes general 
operational requirements such as work week and number of shifts; functional 
requirements including processing algorithms and scene loading; product 
requirements both image and digital; and overall system constraints and 
interfaces related to sensors and spacecraft. 

Section 3 developes point designs for both a central and regional 
image processing facility. Included are estimates of computer resources 
required and architectural alternatives available, for both general-purpose 
and special-purpose processor implementations. Also included ar° put/ 
output configurations related to available digital and image : mg 

equipment. . 

Major conclusions and recommendations L ^lude: 

• Digital image processing systems are feasible. The rec- 
ommended configuration consists of a general-purpose digital 
computer augmented with special-purpose digital hardware, 
an input digital tape recorder and interfacing device, high- 
density digital tape recorders as the primary output device, 
and a laser beam film recorder interfaced to high-density 
digital tape recorders for film imagery generation. 

^ Digital tape recorders with input rates high enough to 
accommodate the EOS satellite transfer rate are not yet 
commercially available. However, given present technology 
they are feasible with minimum d ivelopment cost. 
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• The recommended primary archive is corrected data on high- 
density digital tape. This data may be copied for distribution 
as a product and used as input to reproduction units. These 
modular reproduction units give needed growth and flexibility. 

• Data transfer (inter 7 icing), working data storage, and data 
flow and control (operational timeline) are critical areas 
which will determine the success of a specific design. 

• Efficient means for identifying ground control points in the 
data must be determined to minimize data reprocessing 
compatible with required accuracies and data availability. 


Noted that the processing estimates and system configurations 
developed in this study reflect a low-to-medium scale of detail; it 
would be expected that additional efforts, at a m.ch higher Level of 
detail, be completed prior to final selection of specific system 
conf igurat ions . 
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SYSTEM REQUIREMENTS AMD ASSUMPTIONS 


2.1 INTRODUCTION 

This section discusses the major system requirements and assumptions 
that form the basis of the image processing system (IPS) design approaches 
discussed in sec. 1. Included are direct IPS requirements (user and 
archival products, work week, number of shifts, etc.) as well as overall 
system constraints and interfaces (sensor, spacecraft, etc.) that impact 
the IPS design. 

The data presented » although still preliminary, represents the best 
information available at the time of this study and reflects the judgment 
of the various technology groups in the EOS Project Office at Gcddard. 

In some cases where more than one candidate technology for a given appli- 
cation is being considered (e.g., more than one multispectral scanner is 
currently under consideration), a technology was chosen. 

2.2 GENERAL OPERATIONAL REQUIREMENTS 

The overall EOS mission calls for two basic IPS facilities. The 
first is a main or central facility likely to be located at the present 
ERTS-1 Data Processing Facility site at the Goddard Space Flight Center. 

This facility is to process all the basic scene load obtained from the 
satellite, as well as produce all the image and digital products required 
by NASA users. (Specific scene loading and product requirements are 
outlined in secs. 2,3 and 2.4, respectively.) 

The second facility is a scaled-down version of the central facility 
intended for image processing and product generation for the needs of a 
given region only. These regional facilities, for example, might be 
located in, and operated by, various state authorities throughout the 
U.S. to serve users interested in monitoring state or local resources 
and phenomena only. For purposes of this study, this facility is assumed 
capable of handling up to 30% of the basic scene load and product generation. 
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Each facility is assumed to operate on a seven-dav work week. 
Nominally, two 8-hour shifts are allocated to actual production and the 
remaining 8 hours to daily hardware Goldstar ts, software development, and 
preventive or other unscheduled maintenance. Staffing is therefore 
assumed to require a full four shifts per week for the computer and 
three shifts plus maintenance for I/O units and other equipment. 

2.3 DATA PROCESSING REQUIREMENTS AND ASSUMPTIONS 

All-digital image processing is assumed the only technique. Th^s 

system corrects for radiometric errors and geometric distortions by 
operating directly on the imagery data in digital form, as contrasted to 
a hybrid electro-optical method. Simply stated, digital data defining 
the intensity level of each picture element of a given scene is corrected 
and adjusted using the various computational and operational procedures 
described in sec. 2.3.2. 

The principal factors that impact the processing load for an all- 
digital system are: 

• The scene-based workload, i.e., the number of scenes per 
day, and the data characteristics of a given scene. 

• The specific algorithms chosen as providing a balance between 
accuracy requirements and data processing requirements. 

These factors require judgment and resourcefulness if the data 
processing loads are to be reasonable. The former factor — the number 
of scenes per day — is largly a system design feature that is somewhat 
constrained by system interface constraints (see sec. 2.5), but the 
latter factors, involving the selection of the algorithms to be used, 
exhibit greater leverage with respect to the amount of "computing power" 
required. 


5 



2.3*1 Scene* Based Workload 

As used here, a "scene** is a collection of band-limited frames of 
information originating from two on-board sensors chosen as base-line 
for this study: the thematic mapper (TM) and the high-resolution 

pointable imager (HRPI) . 

A Thematic Mapper Scene Characteristics 

The TM is a bidirectional linear scanner having the general 
characteristics susmaarized in table 1. This sensor gathers data by 
scanning the surface of the earth in swaths measuring 420 m along track 
and 185 km cross track. Seven spectral bands are recorded simultaneously. 
The first six have 14 scan lines per swath, corresponding to 30-m resolu- 
tion each. The seventh has 3 scan lines per swath, corresponding to 140-m 
resolution. 

In general terms, the sensor obtains cross-track data by means of 
an oscillating mirror that reflects light through a single focusing 
optical system. The light is then passed through optical filters unique 
to each spectral band and conducted to individual detectors. Video 
data is recorded during both mirror-scan directions. Signals at the 
detector electronics output (87 channels total) are then sampled, 
digitized, and formatted into a serial digital data stream by a multi- 
plexer similar to ERTS-1 MSS. 

Along-track imagery is produced by the orbital motion of the space- 
craft with the subsatellite point moving 420 m during one-half the main 
mirror-scan cycle. A second mirror corrects for satellite velocity during 
each half scan. 

The basic scene data for the TM is given under item 5 in table 1. 

A TM scene covers 185 km * 185 km on the ground and contains seven frames, 
each consisting of an array of picture elements (pixels). A pixel is 
the encoded radiometric intensity from a detector for the range of 
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TABLE 1 

THEMATIC MAPPER CHARACTERISTICS 


Bidirectional linear scanner having an 8.4-Hz scanner mirror 
frequency with compensated mirror motion. 

Seven bands total: 

a. 6 bands @ 14 detectors/band/cross-track swath 

b. 1 band with 3 detectors per cross-track swath 

Intraband registration errors similar to the ERTS-1 MSS. 

Band pixel intensity data interleaved in data stream similar to 
ERTS-1 MSS. 

Basic Scene Data: 

a. 185 km * 185 km scene 

b. Instantaneous field of view (IFOV) 

6 bands @ 30 m 
1 band @ 140 m 

c. 7 bits/pixcl encoded intensity data 

d. Oversampling to be considered parametrically resulting in 
the following pixels per scene: 

NUMBER OF PIXELS IN A SCENE 


OVERSAMPLING FACTOR 

BANDS 1.0 x l.Q , 1.4 x l.Q 



a- * w 

CROSS | 

| ALONG 

CROSS 

ALONG 


TRACK 

1 TRACK 

TRACK 

TRACK 

1 through 6 

6300 

t 

6300 

8820 

6300 

7 th 

1350 

; 1350 

1900 

| 1350 


Sensor internal errors are to be modeled and compensated in the 
IPS by algorithm. 

The sensor is to have no offset pointing capability. 











frequencies corresponding to a given frame. Each pixel is encoded to 
128 levels of grayness and is represented as a 7-bit quantity. 

The present specifications of the TM call for 1.4 samples per IFOV 
width to be received by the multiplexer and sampler, whereas only 1 sample 
per IFOV is to be received in the direction of the spacecraft velocity. 

The input to the IPS, therefore, consists of a matrix of data points 
where the cross-track spacing between points is 1.4 of the along-track 
spacing. Identically, for every n "lines” of data, we have 1.4n pixel 
values. 

The rationale for oversampling in one direction is debatable since 
the utility of the 40Z increase in data volume in this direction has not 
yet been adequately demonstrated. Indeed, oversampling problems include; 

1. Passing of higher frequencies in the cross-track direction. 

(It is recognized, though, that there is a low-pass noise- 
limiting filter in the sensor that attenuates spatial fre- 
quencies in the cross-track which is somewhat compensated 
for by oversampling.) 

2. Relating the scene loading in terms of bits per day to both 
input to and output from the IPS. 

The latter factor relates to the output data grid functional 
requirements. This grid can be identical in units (but corrected for 
error and projection) to the input grid. However, the non-unity aspect 
ratio (i.e., ratio of distance between cross-track and along-track samples 
in the output data) can make output data analysis difficult: spatial 

fLequency analysis, data classification, and pattern analyses will be 
biased by direction; data handling equipment must be programmed or 
adjusted to account for this aspect ratio. 
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Further implications of this problem are discussed again in 
st:. 2.3.2 under functional requirements. At this time, note that, 
because cf the uncertainty about the utility of oversampling the scene 
loading (sec. 2.3.1.C) was established at the IPS output and, where time 
would permit, oversampling factors (item 5d, table 1) of both 1.4 x 1,0 
and 1.0 x 1.0 were considered in the study. 

B High-Resolution Pointable Imager Scene Characteristic 

The second on-board sensor used as a base line in this study is 
the HRPI . As its name implies, this sensor is pointable and has a 
resolution of the order of 10 m. Its major characteristics are summarized 
in table 2 and fig. 1. 

The HRPI is a four-band sensor whose image is reconstructed from 
a staggered linear array of 4800 individual IFOVs spanning the cross- 
track direction (fig. la). 

In general terms, the sensor operates as follows: Light from each 

IF0V is focused through a common optical system onto a series of dichroic 
mirrors which separate the four bands and impinge them onto four separate 
arrays of detectors. The detector response is them sampled by one of 
4800 diodes arranged on 5 silicon chips containing 10 elements of 96 
diodes each (fig. lb). 

Each IFOV in the combined scene is sampled in sequence using diodes 

on alternate chips. For a given IFOV a single element (fig. lb) samples 

the four bands in sequence. This data is them digitized and pixel 
* 

interleaved in the data stream as shown in fig. lc. 


In summary, then, cross- track imaging for the HRPI is accomplished 
by simply sampling individual detector response in proper sequence. There 
are no scanning components. The along-track imaging is produced by the 
* 

Pixel-interleaved data has geographically identical data for all bands 
in sequential order; band-sequential data is entire frames of data (many 
pixels) in band-by-band order. 
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TABLE 2 

HIGH-RESOLUTION POINTABLE IMAGER CHARACTERISTICS 


Four-band sensor with fixed linear arrays of detectors 

a. 4800 detectors /band with a combined IFOV as shown in 
fig. la. 

b. Single optical system using dichroic mirrors separates 

the bands onto the separate arrays of detectors. 

Detector electionics and readout 

a. Each IFOV is sampled by one of 4800 diodes arranged on 5 
chips containing 10 elements of 96 diodes each (fig. lb). 

b. For each IFOV a single element samples four bands. Data is 
interleaved in the data stream as shown in fig. lc. 

Sensor has offset pointing capability: 

a. ±45° total 

b. 1° increments 

c. ±1 arc sec repeatibility 

Basic Scene Data 

a. 48 km * 185 km scene at zero offset 

b. IFOV: 10 m all bands 

c. Scene requires 4800 pixels (cross track) to 18,500 pixels 
(along track) 

d. 7 bits/pixel encoded intensity data 

Combined sensor internal error to be modeled and compensated in 

the IPS by algorithm: ±1.2 pixels maximum 

Sensor requires nonlinear radiometric calibration. 




a. Staggered Linear Array IFOV Geometry 


5 Chips 


* 10 elements 

h H 


\ 


Q O 0 0 Q 
D O C □ 0 










1 element 

96 diodes 1 

1 I 


Four leads corresponding 
to each band 


b. Detector Electronics 


Figure 1. High-Resolution Pointable Imager Characteristics 
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c. HRPI Readout Sequence 


Figure 1 (Cont.). High-Resolution Pointable Imager Characteristics 



orbital motion of the spacecraft. It should be noted that as the fixed 
array of staggered IFOVs moves forward , 2x4 bands * 4800 IFOV ■ 38,400 
IFOVs must be transmitted to obtain adjacent IFOV in the same line in 
the combined image. This results from the IFOV geometry and nature of 
the diode readout sequence (fig. lc). 

The HRPI basic scene data is given as item 4, table 2. At zero 
pointing offset an HRPI scene covers 48 km (cross track) x 185 km (along 
track) on the ground and contains four frames each consisting of 4800 x 
18,500 pixels. Each pixel is encoded to 128 levels of grayness and is 
represented as a 7-bit quantity similar to the TM. 

C Scene Loading 

As a design point for this study, the basic scene load (i.e., 
actual distinct observations) to be processed through the central facility 
IPS is taken as 10^ output data bits per day from each sensor. Assuming 
a 30% factor (discussed in Sec. 2.2), this is reduced to 3 x 10^ output 
data bits per day per sensor for the regional facility. 

An additional 35% is applied to the basic scene load to allow for 
processing results from: 

1. Alternative processing algorithms (e.g., cubic convolution^ - 
versus nearest neighbor interpolation) — taken as 30% of the 
basic scene load. 

2. User retrospective or duplicate processing — taken as 5% of 
the basic scene load. 

Equivalent scenes per day corresponding to output data bits, for 
each sensor and for each facility type, are summarized in table 3 (see 
sec. 2.5 for the conversion details). 
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2.3.2 Algorithms and Functional Requirements 

Each frame of each scene must be radiometrically and geometrically 
correct. That is, each must be adjusted for known deficiencies and 
variations in the sensor response to impingent intensity sources, and 
each must be geometrically transformed so that the resultant image repre- 
sents a true one. The calibration for the sensor is gathered over a 
period of time and is assumed to be known explicitly. The primary 
information which can be used to generate the necessary transformation 
of each frame to eliminate geometric distortions can come from three 
sources: 

1. Detailed data about satellite position, attitude, and atti- 
tude rates, based on telemetry data and supplementary calcu- 
lations performed on satellite tracking data. 

2. Correlation between one frame of the input scene and similar 
(but independently collected) data corresponding to a ground 
control point (GCP) . (The selection of which of the several 
frames to employ in this role is assumed to be outside the 
domain of this study.) 

3. A combination of GCP and satellite position and attitude 
data. 

For the purposes of this study we assume that GCP techniques are used as 
the primary means of identification of the appropriate transformation. 

At this time no attitude information from AMS measurements is assumed. 

In this study, the major functions performed in processing TM or 
HRPI digital imaging include 

1. Image input : sorting and inventory of pixel intensity 

values to reconstruct frames in the proper sequence. 

2. Radiometric correction : accounts for drift in sensor 

response with time and within each frame. 

3. Ground control point correlation : detection o£ ground control 

points to support identification of the image transformation 
due to external positional errors. 
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4. Offset pointing correction ; for the HRPI identification of 
the image transformation due to offset pointing of the 
sensor. 

5. Inverse transformation generation : use of GCP, offset point- 

ing, and sensor internal error information to generate speci- 
fic transformations applied to the input j'xa,;e to produce 
the corrected scene. 

6. Output image generation : use of the ' rmation and 

video interpolation to identify th .ected pixel values 
for the output scene. This function also includes image 
formatting. 

Other secondary functions include: 

1. Input and output control 

2. Annotation computation including framing, map projections, 
etc. 

3. Establishing ground control point truth data 

4. Internal data management 

The computational flow and interrelationships between these major func- 
tions are identified in fig. 2. 

More specific requirements related to each major function are 
reviewed in the following paragraphs. 

A Image Input 

The TM reads out intensity data directly into a pixel- interleaved 
format with IFOV along a line of a given swath in proper se 4 uence. On 
the other hand, because this scanner records video data during both 
mirror scan directions, adjacent swaths are read out in reversed sequence. 
This requires input sorting and inventory for proper image reconstruction 
during processing. 
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On the other hand, the HRPI requires considerable input sorting 
and inventory that aust be accounted for. This results froa the 38,400 
pixel values separating line adjacent IFOV in the transmitted image, as 
discussed in sec. 2.3.1.B and fig. lc. 

B Radiometric Correction 

Concerning radiometric accuracy, this study assumes that calibration 
errors and other processing distortions (Interpolation, etc.) when com- 
bined will not be greater than ±1 quantum level. 

C Ground Control Point Correlation 

The attitude control system on board the EOS satellite is assumed 
to provide orbit stability considerably improved over the present ERTS»1 
system. A relative comparison of EOS projected attitude control versus 
ERTS-1 experience is given in table 4. 

Because of improved stability, it is assumed that only one scene 
per orbit will require GCP correlations to establish attitude information. 
Seven separate GCP correlations within that scene are assumed adequate. 

In conjunction with GCP correlations, the overall geometrical 
accuracy goal assumed in the study is to have any point in a scene located 
to within ±1/2 pixel of its true position. The ability to locate a 

pixel accurately in an output scene depends not only on properly compen- 
sating for all geometrical errors in the system (sensor, etc.) but also 
on adequately knowing the spacecraft position and orientation through 
ephemeris and attitude data. 

Figure 3 indicates e restraints placed upon the orbital ephemeris 
and spacecraft attitude for allowable '-"l n»r. error for the two space- 
craft sensors, the graph xes to reflect the error in meters 

on the ground resulting frc ", her the ephermerls or the atti- 
tude. The second axis for «..tors, labeled in seconds, represents 
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ATTITUDE ERRORS 



the time required for the corresponding error in meters due to an attitude 
deviation rate assumed for the attitude control system oi 10 ^ deg/s 
(table 4). Indicated on the graph are the curves for ±1/2 pixel total 
error for both the TM and the HRPI with and without system residual 
errors included. (The effects of considering other errors, for example, 
such as ±1 pixel or ±1/4 pixel, can be estimated by simply multiplying 
the numbers on each axis by 2 or 1/2, respectively.) The effects of 
residual errors are included to account for either unmodeled or unknown 
errors which might detract from overall geometric accuracy. These 
would include, for example, the internal errors resulting from sensor 
distortions, and computational errors resulting from approximations 
made in determining the output transformation. The sum total of all 
such unaccounted-for errors was assumed to be less than 20% of 1 pixel. 

D Offset Pointing Correction 

For this study it is assumed that the HRPI sensor will be pointed 
in an offset position for up to 50% of the d.ta it provides. Although 
capable of pointing to ±45°, corrections are only required to ±20°. 

It is assumed that one geometric correction algorithm will be required 
for each 5° incremental change in the offset angle. 

E Inverse Transformation and Output Generation 

Two basic video interpolation algorithms are provided as user 
options: cubic convolution and nearest neighbor. 

Up to 100% of the basic scene load is to be interpolated using 
cubic convolution. Although very close, this algorithm (discussed in 
more depth in sec. 3.2.1) introduces some radiometric distortion from 
"interpolated" pixel values. On the other hand, nearest neighbor simply 
chooses the pixel value of the nearest neighbor to the interpolant point 
without altering its value. For this study, it is assumed that 30% of 
the basic scene load will be reprocessed using nearest neighbor for users 
interested in unaltered radiometric information. 
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Other output requirements and assumptions relate more specifically 
to the TM. Oversampling by a factor of 1*4 in cross track has an impact 
on output grid and interpolation. This problem is introduced in 
sec. 2.3. l.A and is expanded upon here. 

If a choice is to be made to produce output data points equally 

spaced in the horizontal and vertical directions (under control of an 

interpolation algorithm), the two obvious candidates are to produce 1.4 

2 

output lines per input line in the vertical direction giving (1.4n) = 

2 

1.96n output data bytes per n input lines, or to produce 1 output 

2 

sample per 1.4 input sample in the horizontal direction, yielding n 

2 

data points output for every n input lines (1.4n ) input bytes). In the 

first case, the impression may be created that the frequency content of 

the data is higher than is actually the case; a real data volume load of 

40% is imposed on all users of the data in digital format. The second 

case seems to be losing data, and will raise the question of the utility 

2 

of the 40% oversampling performed at the sensor. An objective analysis 
of the electronic bandwidth of the sensor system and the effectiveness 
(accuracy) of interpolation algorithms in producing less than one output 
point per input point is necessary to evaluate the alternative. 

Recall that, to produce useful sizing estimates, the system loading 
was estimated at the output . That is, 10 bits/day/sensor is the 
required unique output from the IPS. Alternative processing is sized at 
35%, giving a total sensor output of 1.35 x 10^ bits/day. The inter- 
polation scheme used in the sizing produces one output pixel byte per 
input pixel; the rectangular output grid is assumed. 


2 

For instance, the McDonnell Douglas study, Ref* 2, applied to the 
current scanner design, with a digital interpolation algorithm and, 
perhaps, a different objective function (error measure). 
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Weighting the computer load estimate for the interpolation and 
output function (sec. 3.2) by 1.4 or 0.715, as appropriate, gives a 
good adjustment to reflect 40% (more or less) output data for the same 
input data. 

Additional output requirements relate to formatting the output 

data: 

1. Subframing capability with and without digital enlargement 
(by interpolation) is required, but for only 5% of the data. 
This is for users interested in only portions of a given 
frame. 

2. Formatting multiple HRPI scenes on the same photographic 
image is required. 

3. Pixel-interleaved output format from the computer to the 
master archival storage (i.e., high-density digital tape) 
is assumed. A discussion of the rationale for this format 
is presented in sec. 3.2.3.D. 

The details behind the specific algorithm selected to perform the 
above functional requirements including processing load estimates is 
given *.n sec. 3.2. 

2 . 4 PRODUCT REQUIREMENTS 

Products defined in this study for system sizing are summarized in 
table 5. Basically, two general types are required: 

1. Digital data stored on high-density digital tape (HDDT) and 
computer-compatible tape (CCT) 

2. Imagery data on 9.5 in master film, scale 1:10^ 

In each case, archival products for storage are distinguished from user 
products intended for distribution. 
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TABLE 5 

SUMMARY OF PRODUCT REQUIREMENTS 


Digital Data 

1. High-Density Digital Tape 

a. Archival Products 

- Two copies of all data (i.e. , 1.3S times 
basic scene load) 

- Pixel-interleaved format 

b. User Products 

20Z of all data 

Interleaved or band-sequential format 

2. Computer-Compatible Tape (User Products Only) 

a. 6250 or 1600 Bits/ In Tape 

b. 10Z of Basic Scene Load 

c. Editing and Subframing Capability 

Imagery Data 

1. 9.5 in Film Images (Scale 1:10^) 

a. Archival Products 

Two copies of one band for each sensor 

- Cubic convolution Interpolated data only 
Black and white copies (growth capability 
for color) 

b. User Products 

- Up to 50Z of all cubic convolution 
interpolated data 

Black and white copies (growth capability 
for color) 
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These requirements were chosen as representative of the need at 
the time of this study, but are by no means definitive. Indeed, ERTS-1 
experience has shown that product requirements, particularly product 
quantities, tend to expand as new applications of the data become known. 
This should be kept in mind and a system design provided that has growth 
capability. 

2.4.1 Digital Products 

Archival requirements for digital data include two copies of all 
the data processed (i.e., 1.35 times the basic scene load) stored on 
HDDT in pixel interleaved format (a rationale for this format is presented 
in sec. 3.2. 3. D). HDDT is assumed the master archival storage medium for 
all data produced. 

User digital products, both standing order and retrospective, are 
assumed required for up to 30% of all data processed. This includes 
20% on HDDT and 10% on CCT (intended for users with limited equipment 
and/or data requirements). 

HDDT products are required in both pixel interleaved and band 
sequential formats. Also CCT production should include editing and sub- 
framing capability. 

2.4.2 Imagery Products 

Archival requirements for imagery data include two copies of one 
frame of each scene (from both sensors) recorded on a 9.5 in film format, 
scale 1:106. Currently the copies can be black and white, but growth 
capability to color should be kept in mind. The copies are required 
for cubic-convolution interpolated data only. 

User imagery products are assumed required for up to 50% of all 
cubic convolution interpolated data. Again, copies can be black and 
white but growth capability to color should be kept in mind. 
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2.5 INTERFACE CONSTRAINTS 


2.5.1 Introduction 

During this study, various requirements were established for such 
quantities as total data volume., scene coverage, sensor resolution, and 
transmission rate. Since a number of these are interrelated, analysis 
was required to show their interaction in a parametric way. The results 
presented in graphical form here, were used to insure that a self-consis 
tent set of requirements was selected for the point design. 

In summary, the analysis showed that the following base-line re- 
quirements used for this study are self-consistent: 

IPS Loading 

• 1.0 * 10^* bits per day per sensor from the satellite 

• 1.35 * 10^ bits per day per sensor to be processed 

Sensors 

• Thematic mapper 

• Scene ” 185 km * 185 km 

• Framing ■ 7 bands per scene, with 30-m IFOV in bands 
1-6, 140-m IFOV in band 7 

• Bits per pixel ■ 7 

• Processor time available * 8 hours 

• Sample overlap * 1.0 x 1.0 and 1.0 * 1.4 

• 6300 pixels per line @ 1.0 * 1.0 overlap 

• 8800 pixels per line @ 1.0 * 1.4 overlap 
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• HRPI 

• Scene » 48 km * 185 km 

• Framing * 4 bands per scene with 4800 detectors per 
band and 10-m 1F0V 

• Bits per pixel * 7 

• Processor time available * 8 hours 

Orbit 

• 914 km circular, polar orbit similar to ERTS-1 

Data Transmission 
, * 

• 120 Mb/s per sensor real time only 

• £20% overhead for the thematic mapper 

• £5% overhead for the HRPI 

Two important interface constraints appearing above and not dis- 
cussed elsewhere are the satellite orbit and data transmission. The orbit 
presently specified is similar to ERTS-1 with an altitude of 914 km, 
giving an 18-day repeat cycle. The communications link is presently 
X-band with a transmission rate of 120 Mb/s for each sensor. Sensor 
overheads are specified at £20% for the thematic mapper and £5% for 
HRPI. It should be emphasized that no means of data storage was considered 
for on board the satellite resulting in real time data acquisition only. 
Three acquisition stations specified for this real-time-only data reception 
are located at Goddard, Fairbanks, Alaska, and Golds tone, California. 


* 6 
Mb 2 bits * 10 . 
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2.5.2 Thematic Mapper Interface Analysis 

Three sets of graphs were drawn for the TM to show the interrelat- 
ionship of the total number of bits per day processed, the transmission 
rate, the processing time available, and the number of pixels per line. 

In addition, the number of pixels per line is determined by the cross- 
track swath width, the sensor resolution, and the amount of sample over- 
lap in the cross-track direction. Two sample {overlaps were considered: 

1.0 x 1.0 sample overlap indicates that one sample per IFOV is taken in 
each direction, 1.0 * 1.4 sample overlap indicates that one sample per 
IFOV is taken in the along-track direction while 1.4 samples per IFOV 
are taken in the cross-track direction. 

The following parameters (consistent with table 1) were used In 
calculating the graphs: 

• Scene • 185 km x 185 km 

• Framing * 7 bands per scene, with 14 detectors in bands 1-6, 

3 detectors in band 7 

• Coverage * 25 to 75 scenes per day 

• Bits per pixel * 7 

• Processor time available ■ 8 hours 

• Sample overlap * 1.0 x 1.0 and 1.0 * 1.4 

• Orbit ■ 914 km, circular 

Figures 4a and 4b showing pixels per line versus bits per day for the 
two sample overlaps were computed by converting the number of pixels per 
scene to bits per scene and multiplying by the desired number of scenes 
per day. For the desired processing load (1.35 x 10** bits/day) the re- 
sulting number of pixels per line is indicated for each sample overlap. 
(This results in 6300 pixels/line for 1.0 x 1.0 overlap as shown in fig. 

4b and 1.4 x 6300 * 8800 pixels/line for 1.0 x 1.4 overlap as shown in 
fig. 4a.) From fig. 4b, it is clear that up to 80 scenes per day can 
be processed at the design point. This number reduces to 57 scenes per 
day in fig. 4a because of the 1.4 overlap factor. In order to achieve 75 
scenes per day, the number of bits per day must be increased to 1.8 x 10**. 
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Figure 4. Thematic Mapper - Pixels per Line vs. Bits per Day 
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Figure 5. Thematic Mapper - Transmission Rate vs. Pixels per Line 
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Figures 5a and 5b show transmission rate versus pixels per line. 
These graphs were computed using the equation 

(pixels/ line) = [(bits/s) (25 s/scene/ 

x (1 ~ Overhead) (overlap factor) (1 pixel 1 ,its) 

* (1 scene/6 frames) 


Overhead is defined as that portion of the transmitted signal which does 
not enter the processor but is used for parity checks, etc. Six frames 
per scene were used because of the lower resolution in the seventh band. 
Indicated on the graphs is the number of pixels per line resulting from 
the specified transmission rate o f 12C Mb/s. At both sample overlaps, 
no problem is encountered for real-time data transmission of up to 

20% overhead. However, at an overlap of 1.0 x 1.4, 9000 pixels per 

line is the maximum obtainable. If mor* per line are desired, 

either the overhead must be reduced or the cr<uu.rtis&ion rate must be 
increased. The total number of bits or scenes per day in dependent 
upon the length of transmission time. 

Figures 6a and 6b show the relation of pixels per line to available 
processing time. These graphs were computed from figs. 4a and 4b by 
converting bits to pixels and an 8-hour processing day into microseconds. 
Indicated on the graphs are the number of pixels per lire (determined 
from previous graphs) and the maximum processing time available per pixel 

(1.5 Usee) at a data load of 1.35 * 10^ bits per day. For x.O * 1.0 

overlap, fig. 6b indicates that it is possible to process more than 75 
scenes per day at 1.5 Us per pixel processing speed. Figure 6a (1.0 * 

1.4 overlap) shows that 1.2 us per pixel are available to process 75 
scenes in 8 hours. Implicit in the graphs is the fact that, if the 
processing is to be completed in less than 8 hours, the processing 
time required per pixel is loweied by a proportional amount 
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Figure 6. Thematic Mapper - Pixel per Line vs. Processing Time 
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2.5.3 HRPI Interface Analysis 

The three types of graphs drawn for the HRPI sensor show the rela- 
tion of the total nuaber of bits per day, the transmission rate, the 
processing time available, and the along- track resolution (or the ground 
spacing of adjacent IFOVs between successive sampling of a detector). 

The parameters used for calculating the graphs include the following: 

• Scene ■ 48 km * 185 km 

• Framing ■ 4 bands per scene with 4800 detectors per band 

• Coverage = 25 to 75 scenes per day 

• Spacecraft ground velocity * 6.47 km/s (914-km orbit) 

• Bits per pixel = 7 

• Processor time available = 8 hours 

In fig. 7, resolution versus bits per day is indicated for 
the specified data load of 1.35 x 10^ bits per day and the desired 
resolution of 10 m. The graph was computed using the equation 

(bits/day) - (4800 pixels/line) (1.85 x 10 5 m/frame) 
x (line/resolution in m)(4 frames/scene) 
x (scenes /day) (7 bits/pixel) 

At 10-m resolution, 54 scenes per day are possible for the 1.35 x 
10^* bits per day. In order to reach 75 scenes per day, 1.85 x 10^ bits 
must be processed each day. 

Figure 8 shows the relation of resolution to transmission rate. 

The graph was computed using the equation 
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Figure 7. HRPI - Resolution vs. Bits per Day 




140 



35 


Figure 8. HRPI - Resolution vs. Transmission Rate 



3 

(number of bits/s) = (6.47 * 10 m/s) (line /resolution in m) 

x (4800 pixels/line) (4 bands) 
x [1/(1 - overhead)] (7 bits/pixel) 

Where overhead is defined as that portion of the transmitted signal which 
does not enter the processor but is used for parity checks, etc. For 
10 -q resolution, over 20 % overhead is allowable at 120 Mb/s; but when 
the resolution is increased to less than 10-m the required transmission 
rate begins to increase rapidly. 

Resolution versus processing time available, shown in fig. 9, was 
computed from fig. 7 by converting bits to pixels and an 8-hour processing 
day into seconds. If the maximum amount of time available per pixel (1.5 us) 
is used, only 54 scenes per day can be processed. To obtain 75 scenes 
per day the processing speed must be increased to 1.1 us. 
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Figure 9. HRPI - Resolution vs. Processing Time 
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DESIGN APPROACHES 


3.1 INTRODUCTION 

This section develops point designs for both central and regional 
image processing facilities. These designs Incorporate the operational 
and functional requirements, products, and system constraints discussed 
in sec. 2. 


Where possible, currently available or near future technology are 
identified and incorporated into the designs. This includes: general- 

purpose computer hardware, special-purpose digital hardware, high-density 
digital recorders, and image recorders. If specific hardware was found 
inadequate, the required improvements are identified. 

The resulting designs reflect a low-to-medium scale of detail; it 
would be expected that additional efforts at a much higher level of de- 
tail be completed prior to final selection of specific configurations. 

One should note that the intent was to establish technical feasibility 
and first-order costs only. Indeed, the designs developed reflect simply 
one way of approaching the problem — one that is not necessarily optimal. 

The following sections discuss the central and regional facilities 
separately. For convenience, the IPS for each facility is broken down 
into three basic stages — preprocessor (or input), processor, and post- 
processor (or output). 

3.2 CENTRAL FACILITY CONFIGURATION 

The general configurations studied Involve (1) the use of a large- 
scale, general-purpose digital computer system, and (2) the combination 
of a large- or medium-scale general-purpose machine with special-purpose 
hardware. These are shown in fig. 10. 
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a) General-Purpose Processor Organization 



b) Special-Purpose Processor Organization 


Figure 10. General-Purpose and Special-Purpose/Host Computer Organizations 
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The investigation includes (1) specification of the total computa- 
tional burden (i.e., that imposed by the data loading) which must be 
borne by the IPS; (2) the identification of appropriate processor config- 
urations which can support the required computation rates; and (3) iden- 
tification of appropriate preprocessor and post-processor configurations 
which can support the required data input and output rates and product 
requirements. Items 1 and 2 are addressed in sec. 3.2,1 for systems 
centered about general-purpose processors exclusively; and in sec. 3.2.2 
for systems incorporating special-purpose hardware. Item 3 is addressed 
in sec. 3.2.3 for both configurations. Finally, sec. 3.2.4 provides a 
summary of the recommended configuration. 

3.2.1 Systems Centered About General-Purpose Processors Exclusively 

A Computer Resource Estimation 

In this section we develop detailed estimates for the data process- 
ing resources required for processing the TM and HRPI image data. These 
estimates are expressed in a relatively machine-independent form; relating 
the estimates to actual machine architectural configurations is addressed 
in the next section. 

(1) Estimating Procedure and Assumptions 

(A) Data Processor Estimates 

For the purposes of computer resource estimation, we assume that 
the EOS data is manipulated on a general-purpose computer system which 
possesses infinite local memory. The general-purpose processor is 
assumed to have a typical complement of instructions which operate in 
strictly serial fashion. Algorithms implemented on this processor have 
aggregate execution tires which are directly related to the overall 
instruction counts incurred by the algorithm. The computer resource 
estimates are expressed in terms of " standard instruction executions. 1 ' 
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Of course, there is no such thing as a "standard instruction"; 
typical image processing algorithms employ a wide variety of machine 
instructions. For estimation purposes, however, we take the fixed-point 
add operation as the standard of comparison, and relate the difficulty 
of all other operations to this particular instruction. The fixed-point 
add operation is assumed to act in the following way: it retrieves one 

operand from processor memory, adds the operand to the contents of one 
of the processor's operating registers, and leaves the result in the 
operating register. 

The relationship between this standard instruction and other common 
processor operations is taken as the following: 

Fixed multiply operation = 2 fixed add operations 
Fixed divide operation * 4 fixed add operations 

(B) Computer Memory Estimates 

Estimates of required memory can be made independently of the 
estimates of required processor "power," provided that (1) the actual 
computer system is relatively insensitive to the assumption of infinite 
memory, and (2) the actual computer system has "sufficient" internal 
storage to support execution of the algorithms. 

(C) Input /Output Capacity Estimates 

The actual EOS computer system must have sufficient I/O capacity 
to support the estimated data transfer rates. As with estimates of 
processor memory size, estimates of required peripheral capacity can be 
uncoupled from processor estimates provided that there is sufficient 
capacity in actual machines. Transfer rates on typical computer systems 
are only a weak function of processor activity, since these operations are 
overlapped with processor functions. Hence, estimates of peripheral 
capacity are unimportant in regard to processor estimates so long as there 
is a capability for multiplexing system 1/0 and processor use. In other 
words, with present-day computer architectures, it is generally possible 
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to replicate I/O capacity without excessive interference with processor 
capacity. 

(2) EOS MIPS Estimates For Each Major Function 

The computing requirements for each EOS processing step can be ex- 
pressed in terms of the total number of instructions; this value varies 
with the type of algorithm performed and with the total size of each 
image frame (i.e., spectral band within a scene). The EOS data process- 
ing facility is projected to operate 7 days per week, 16 hours per day; 
this assumption is then used to compute the number of instructions 
per second (expressed in MIPS, or millions of instructions per second) 
which must be delivered by the EOS computer system. 

(A) Basic Parameters 

The TM and HRPI parameters which must be used to guide these compu- 
tations are : 


TM HRPI 


Input Scenes/Day 



Basic Scene Load 

42 

40 

5% Retrospective Processing 

2 

2 

TOTAL 

44 

42 

Output Scenes/Day 



Cubic Convolution Interpolation (100%) 

44 

42 

Nearest Neighbor Interpolation (30%) 

TOTAL 

13 

57 

12 

“ 5T 

Scene Data 



Number & Size of a Frame (Pixel) 

6 <? 8320 x 6300 
1 0 1900 x 1350 

4 0 4800 x 10,500 
3.552 x lo 8 

TOTAL (Pixel/Scene) 

3.36 x 10 8 


(B) Scene Input 

Each scene's pixel data must be made local to the EOS processor 
prior to the radiometric correction stage (see (C) below). For 
the HRPI scenes , this step involves "unscrambling" of the image data 
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into the "natural" internal order. This situation arises because the 
HRPI sensors are organized in a manner which results in adjacent pixels 
bein'; up to 38,000 pixel positions apart in the input stream. The algo- 
rithmic solution to this "unscrambling" operation is relatively straight- 
forward, requiring only the reservation of approximately 38,000 bytes of 
processor memory as a "loop" in which the intermediate pixel values are 
stored prior : j their final association according to the adjacency rules, 
and prior to delivery to mass storage for later processing. Other over- 
heads may be involved, but it is evident that allowing one instruction 
execution (equivalent) per pixel tor the input phase is more than suffi- 
cient. 

(C) Radiometric Correction 

The radiometric correction stage compensates for time and spatial 

variations in the sensor sensitivities. For estimation purposes, we 

assume that the radiometric correction can be performed for relatively 

large numbers of pixels located in a set of subframe areas; a subframe 

* 

area containing approximately 529 such areas. This number corresponds 
to partition! the data into 23 regions in each dimension. 

The instruction counts for each subframe correction are as follows: 

4 

TM^ 14.7 x 10 instructions/subframe 

4 

TM^ 0.5 x 10 instructions/subframe 

A 

HRPI 24.1 x 10 instructions/subframe 


Note that for the HRPI data it may be necessary to perform this correc- 
tion pric*. to the '•input" stage operations which unscramble pixel posi- 
tions. However, the order in which these two operations is performed 
does not affect the overall instruction counts. 


43 


where TM^ and TM^ represent the six higher resolution frames and the 
lower resolution frame, respectively. The total number of instructions 
required for each scene which result from this computation are as Jollows: 

g 

TM 4.69 x 10 instructions/scene 

o 

HRPI 5/10 x 10 instructions/scene 

(D) Ground Control Point Correlation 

In the EOS only one ground control point (GCP) correlation computa- 
tion is performed for each complete orbit of the satellite. The remainder 
of the information necessary to develop the derailed geometric correction 
transformation is derived from tracking data. The instruction counts fcr 
this computation have already been developed in ref. 3: in this case, we 
assume a GCP search region of 512 x 512 pixels in size, and a correlation 
region of 256 x 256 pixels. With these values, using the algorithm 
described in ref. 3, and dividing the GCP load among the total number of 
scenes/ sensor /day, we arrive at the following instruction counts: 

TM 1.67 x 1(T instructions/scene 

HRPI 1.52 x io^ Instructions/scene 

(E) Offset Pointing 

The HRPI can, as we have already noted, be pointed off the "bore- 
sight" by as much as 45° in either direction. As much as 50% (the assumed 
value here) of the HRPI data will require some compensation for the off- 
boresight pointing angle. This compensation amounts to a remapping 
algorithm which "expands" the scene to conform to the equivalent scene a3 
it would have appeared from a 0° offset angle; the actual transformations 
required would, of course, be a function of the exact offset angle. It 
is expected that one such transformation algorithm would apply to a range 
of offset angles, so that only a few such transformation algorithms would 
have to be maintained. We assume that all such algorithms require the 
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same computational resource, which amounts primarily to a one-for-one 
replacement of pixels from the uncorrected scene to the corrected scene. 

The additional instruction required for 50% non-zero pointing angle is: 

q 

HRPI 1.6 * 10 instructions/scene 

(F) Inverse Transformation 

After sufficient information about the scene is available (and after 
correction of thr offset pointing error, if any), it is necessary to 
generate the exact transformation which will be used to generate the 

geometrically correct output frame from the uncorrected input frame. 

This transformation is approximately equivalent to that described in ref. 3 
ref. 3 with the exception that it must be applied to a different number 
of frames. The number of instructions required is as follows: 

TM. 4.38 x 10"* instructions/frame 

6 

TM^ 0.04 x io^ instructions/frame 

HRPI 3.54 x 10^ instructions/frame 

After the transformation is generated (as •' N x N grid matrix, 
where N ranges in sizes from 8 for TM^ to 96 for HRPI), this transf ormation 
must be applied to develop the mapping functions which will determine 
the regions \ ithin which actual output pixel locations all remain within 
contiguous input-frame pixel quads. Applying this transformation requires 
the following number of instructions. 

2 8 

TM 330M + 1809GM + c.78 x 10 instructions/scen* 

HRPI 165M^ + 19048M -t- 2.72 x 10^ instructions/scene 

and, for M (the number of pixels between grid lines) = 1000, the following 
instruction counts result: 
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TM 


HRPI 


6.26 * 10 instructions /scene 

g 

4.56 x 10 instructions/scene 


voj Output Image Pixel 

The regions identified in the foregoing computations are those in 
which interpolation of the output frame pixel values can occur relatively 
easily. Two algorithms for this output interpolation are employed in the 
EOS: 

1. The nearest neighbor interpolation scheme, in which the 
output pixel value is taken as the value of the input image 
pixel nearest to the location of the output image position 
within the input image pixel grid. 

2. The cubic convolution interpolation scheme, which computes 
output image pixel values using an approximation to the 
(sin x)/x functional form known to be optimal for the types 
of sampling performed by the sensor systems. 

Because these computations are performed so often, it is Important 
to have firm instruction count estimates for them. 

Nearest Neighbor Interpolation . This computation is relatively 

simple, and, as has been described in ref. 3, can be performed with an 
effective instruction cost of 2 instructions/pixel. The total instruc- 
tion count for nearest neighbor interpolation therefore: 

8 

TM 6.72 x 10 instructions/scene 

g 

HRPI 7.256 x 10 instructions/scene 

Cubic Convolution Interpolation . The cubic convolution interpola- 
tion scheme is based on the assumption that the output amplitude at a 
particular point can be expressed in the form: 
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4 

A(x) = £ A(x. )f(x - x.) 
i=l 1 1 

where the x^ are the input-pixel positions, x is the location (in the 
x-direction) of the desired output pixel, f(.) is the unit impulse re- 
sponse at x « 0, and A(.) is a predetermined function which is the basis 
of the transformation. Four steps are required to determine the value 
of the signal at position x; _hese steps are then repeated in the y- 
direction to arrive at the approximate (i.e., the interpolated) output 
value. The four steps are: 

Step 1: Computation of the four differences (x - x^), i = 1, 2, 3, 4 

Step 2: Combination of these differences with input pixel amplitudes, 

i.e., the computations: A^(x - x^)-(x - x^) , i « 1, 2, 3, 4 

Step 3: Use of these values as indexes into four precomputed 

tables which represent the partial contribution of each 
pixel to the output pixel amplitude 

Step 4: Addition of the four selected table values to arrive at 

the output image pixel value 

This computation requires the following instruction executions: 

Step 1: 4 subtractions * 4 equivalent adds 

Step 2: 4 multiplications = 8 equivalent adds 

Step 3: 4 table accesses = 4 equivalent adds 

Step 4: 3 additions * 3 equivalent adds 

Total 19 equivalent adds 

Because this computation is performed for each pixel in both the x- and 
the y-direction, the total instruction count for the cubic convolution 
algorithm is: 

Cubic Convolution: 38 instructions/pixel 
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We can now compute the total instruction counts necessary for 
generation of TM and HRPI output images, as follows: 

™ 1.242 < 10 3 * * * * * * 10 instructions/frame 

HRPI 1.342 x 10 10 instruct ions/frame 

In addition to the computational burden as indicated by the fore- 
going instruction counts, the EOS computer system will require a certain 
portion of its resource to control all activities extant at any one 
instant. For EOS we expect a somewhat greater system overhead than for 
all-digital ERTS discussed in ref. 3. And as a result, we assume 
approximately 15% additic ^1 resource devoted to operating system 
functions . 

(H) Summary MIPS Estimates 

Table 6 shows the summary MIPS estimates for EOS. These values were 
arrived at by multiplying the per frame or per scene counts indicated 
above by the total number of scenes and dividing by the number of seconds 
of execution time available in the assumed workday. 

(3) EOS Computer Memory and I/O Requirements 

The memory requirements for the EOS machine can be analyzed in 
terms of the amount of information which must be available to any algorithm 
at any instant. It is clear that EOS pixels can be stored in 8-bit bytes, 
so that the analysis can proceed in terms of the numbers of pixels which 
must be local to the processor at any instant. (It is important to note 

that "local” does not necessarily mean that the data is stored "in core," 
but only that the data be stored somewhere on the machine's primary/ 

secondary memory complex in such a way that any executing algorithm is 
never "starved" for data by virtue of the data allocation chosen.) The 

largest frame in the EOS specifications is HRPI frame, with approximately 

90 million pixels; if the memory capacity is sufficient for processing of 

this frame, it is also sufficient for processing of all other types of 

frames (i.e., TM^ and TM^) . 
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TABLE 6 

EOS MIPS ESTIMATES 


THEMATIC MAPPXR 
44 Input Scenes/b<.7 
57 Output Scenes/Pay 

(MIPS) 


KRPI 

42 Input Scenes/Day 
54 Output Scenes/L_ , 


(MIPS) 


1 Input 0.260 

2 Radiometric Correction 0.359 

3 Ground Control Point 0.520 

Correlation 


0.262 


0.371 


0.525 


4 Offset Pointing 
Correction 


0.131 


5 Inverse Transformation 0.478 

6 Output Interpolation 

6a Nearest Neighbor 0.155 

(30% of Input) 

6b Cubic Convolution 9.648 

(100% of Input) 

7 Operating System 1.260 

Overhead 


0.335 


0.158 


10.032 


1.260 


Subtotal 


TOTAL 


49 



The total memory space on contemporary computer systems is clearly 
sufficient to store a number of complete frames. For example, the IBM 
3330 disk system with 8 spindles (but without the double-density option) 
option) can store 800,000,000 bytes; this is enough space for 11 complete 

frames. Typically, internal working memory (core storage) consists of 
2 * 10 6 bytes or more. (This may exist as 512K 4-byte words, for example.) 
Thus, at least 2% of the largest frame can be resident at one instant; 
or, more practically, about 1% of a frame can be operated upon at any 
one instant, allowing 50% of the active memory as a transfer area. This 
memory configuration is insufficient to support the algorithms’ execution 
only in case any algorithm requires less time to process 1% of the data 
of the largest frame than it takes the memory system to transfer an equal 
amount to and from the working memory region. 

The transfer rate for the IBM 3330 disk system is 0.806 x ic.6 
bytes/s; this transfer can occur to a processor memory region not used 
by the processor (i.e., the input/output buffer section) essentially 
without interference with the processor operation. Transfer of an entire 
HRPI frame to or from memory requires, therefore, on the order of 112 s. 
Assuming (conservatively) that the 468 input frames to be processed each 
16-hour day are all HRPI frames, approximately 123 s are available to 
process each frame. (It requires a 26-MIPS machine to do this, of course.) 
Thus, a 2 million byte central memory (core memory) appears to achieve 
a closely balanced operation in which 123 s of processing is overlapped 
with 112 s of input/output transfer of the just-processed, or about-to- 
be-processed, image data. It is important to note that this illustration 
of memory balance estimation is based on existence of only one 0.8-mega- 
byte channel; if more channels are available, then the input /output func- 
tion can be performed in parallel, and the period during which processing 
and input and output must overlap is reduced to only 60 s. It is clear, 
however, that a single processor must have sufficient storage space to 
contain approximately 2% of the largest frame if the execution is not 
to outrun the data manipulation. 
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B General-Purpose Processor Architectural Alternatives 

The estimated total machine processing load for a system incorpora- 
ting a single, general-purpose processor was shown to exceed 26 MIPS 
(tcble 6). 

Table 7 provides a preliminary indication of the range of large- 
scale general-purpose computer systems presently available including 
processing capability. These particular machines are mentioned because 
of the clearly indicated need for substantial machine computing resource, 
as well as the corresponding need for substantial amounts of memory and 
peripheral storage capability. (A further discussion of table 7 is given 
in sec. 3.2.2.) 

As one can see, the large amount of computer power required far 
exceeds present capabilities. Indeed this clearly indicates the need 
to consider functional off-loading and special-purpose hardware alterna- 
tives to the use of a single, large-scale, general-purpose computer. 

This option is investigated in the following section. 

3.2.2 Systems Incorporating Special-Purpose Hardware 

A Off-loading Principles 

Faced with heavy computational loads, the first approach to system 
design is to identify functions which can be performed "off line" y 
other special-purpose computer systems without deleteriously affecting 
the effectiveness of the computations performed. The first choices for 
such offloading are clearly those EOS functions which are the greatest 
contributors to the overall processing burden. In particular, the cubic 
convolution computation outweighs all of the other functions to be per- 
formed by the EOS computer. Removing this function to an off-stream 
processor of some kind will reduce the overall computing requirement by 
approximately 18 MIPS, under the assumption that the offloading removes 
90% of the original computational burden. 
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al judgement based on intrinsic nature of EOS problem. 



The potentially applicable offloading computer system architectures 
which appear to have the appropriate general features to perform this 
function are the following: 


1. The use of a collection of fully microprogrammed medium-scale 
computers which are optimized to perform the table lookups 
and simple arithmetic. 

2. The use of one or more special-purpose "signal processor" 
class machine which is hard- or soft-wired to perform the 
cubic convolution algorithm. 

3. The development of special pipeline execution units which 
are hard-wired to perform the specific computation. 

4. The use of some form of distributed computer system which 
allocates load among available processing units automatically. 


(The last alternative is included as a suggestion of a route which could 
be taken to amassing the 20 MIPS required, but it is less a real possi- 
bility than the others because the necessary network control algorithms 
and required efficiency within such a network are not necessarily within 
the present state of the art. Reference 2, for example, examines some 
of the problems with this approach.) 


Figure 10 shows the general difference between use of a general- 
purpose computer and a special-purpose computer system. In the latter 
case, it is likely that there will be sufficient savings to warrant a 
much smaller "host" computer. As a result, it will be necessary to review 
whether it is desirable to offload other functions. Thus, we arrive at 
the following candidate list for offloading (the other EOS functions not 
being amenable to this role) : 

1. The radiomen. ic correction of input data to account for 
variations in sensor response 

2. The computations associated with ground control point corre- 
lation 
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3. The video interpolation of corrected output image pixel values 
from the input image pixel values 

These functions are desirable off-loading candidates for the following 
reasons : 

Radiometric Correction : As we have indicated before, these correc- 

tions can probably be performed with a simple table lookup proce- 
dure. Because the sensor response variations are only a slowly 
varying function of position within each TM or HRPI frame, the 
values in the table must be changed only relatively infrequently 
compared with the total number of pixels which must be processed. 

Ground Control Point (GCP) Correlation ; This computation compares 
a given picture region (ground truth) with the input image as a 
means to precisely identify the true location of the sensed image 
of a particular ground feature. Various "hands off" algorithms 
exist to perform this computation; in addition, the possible neces- 
sity for interactive operation of the GCP operation further sug- 
gests its possible implementation off-line from the main general- 
purpose processor activity. 

Video Interpolation : As the values of table 6 suggest, thii is 

the most likely candidate for offloading. In addition, the speci- 
fic algorithms which must be used (see below) are particularly 
amenable to special-purpose processor implementation since they 
possess these qualities: 

• Regularity of application. (They are applied repetitively 
to a large number of successive pixels.) 

• Simplicity in required addressing patterns. (The algorithms 
can be organized to operate on input-image data in particu- 
larly convenient address patterns as processing of an entire 
frame proceeds.) 
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B Candidate Special-Purpose Hardware 

The special-purpose hardware configuration shown in Fig. 10b sug- 
gests that candidate special-purpose hardware must meet a number of con- 
straints, among them: 

• Capability for full self-operation without undue assistance 
provided by the host processor (which, presumably, is busy 
performing other activities) . 

e The power to access data directly from either primary or 

secondary storage supplied by the general-purpose processing 
system. This is necessary in order to minimize the total 
data movement. 

• The capability to implement the candidate off-loadable 
functions. 

Specitic architectural alternatives are, therefore, limited to thosfe 
special-purpose systems which are complete processors, and to those which 
have the auxiliary functions to support the interactions necessary for 
the entire computation to ,: go through" with minimum delay and inter- 
processor interference. 

(1) Architectural Alternatives 

Two principal architectural alternatives exist which can meet these 
criteria and at the same time offer the potential for significant execu- 
tion time saving by providing for especially efficient implementations. 
These alternatives are : 

1. The use of dynamically microprogrammable off-line processors, 
accessing from the "host" computer primary or secondary (ran- 
dom access) memory system 

2. The use of hardwired processor techniques, in which algorithms 
are selected beforehand and which, because of the implementa- 
tion, can be made to operate at circuit logic speeds. 

* 

These alternatives are the same ones considered in an earlier report, 

Ref. 3. 
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Certain general advantages and disadvantages exist for each of these 
alternatives, as discussed below. 

(A) Advantages 

A dynamically microprograiranable architecture has the advantage that 
algorithm selection is not necessarily permanent. That is, after an effi- 
cient implementation is completed and checked out, and after operational 
experience has been gained with the algorithm and the processor executing 
it, it remains possible to "back up" and make modifications for further 
performance enhancement. 

The use of hardwired logic, however, offers some appreciable speed 
advantages. This situation occurs because of the nature of algorithmic 
processes; that is, a result of the lack of uncertainty in hardwired logic 
implementations. That same uncertainty (manifest in the form cf condi- 
tional checking, and all the other trappings of software) works to "slow 
down" even the best microprogramming implementations. 

(B) Disadvantages 

Hardwired logic has an advantage in speed, but suffers severely in 
terms of overall flexibility. If the algorithms must be changed this can 
be accomplished only by complete rewiring of the special-purpose device (s). 

The use of a dynamically microprogrammed processor has the disadvan- 
tage that a separate software system must be operated. The flexibility 
such a choice offers may not necessarily be offset by the increased system 
programming burden frequent (or even infrequent) changes in the software 
will evoke. 

(2) Candidate Architectures 

Three candidate special-purpose architectures have been selected 
from a large number of those presently under development within the comput- 
ing industry. The selection of these systems as candidates implies neither 
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acceptance of their capabilities for the EOS data processing system nor 
acquiescence to claims of superior design. Likewise, these architectures 
are not to be considered as "eliminated" from further consideration. 


The three candidates are: 

1. The Control Data Corporation "Flexible Processor." This 
machine, which is currently under advanced development, fea- 
tures a relatively large control store and microprogram word 
length, particularly convenient input/output facilities, and 
relatively fast fixed-point-oriented internal processor com- 
putational resources. Internal processing is based on a 125- 
ns clock. 

2. The Culler- Harrison, Inc., "AP-120" Signal Processing System. 
This computer system was developed for a role in signal pro- 
cessing and is specifically oriented to spectral computations 
involving Fast Fourier Transforms (FFTs). Besides a novel 
arrangement for partially dynamic microprogram control, this 
machine has a highly flexible control/data store as well as 
read-only storage for constants and pre-defined functions. 
Internal processing is based on a 125-ns clock. 

3. The General Dynamics 1 High Speed Parallel Digital Processing 
Equipment. This equipment line is aimed at hardwired imple- 
mentations of digital logic on fixed point values for very 
high data rates. Use of ECL 10,000 logic permits processing 
speeds of up to 37 * 10^ operands per second. Although the 
primary orientation of this processor system is toward FFT- 
related applications, the implementation is potentially capable 
of use in the aforementioned ERS computational roles. 
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C Candidate Machine Architectural Details 

This section presents some of the salient features of these three 
candidate special-purpose architectures* Table 8 presents a summary of 
each architecture and an estimate of system cost. 

(1) Control Data Corporation, "Flexible Processor 11 

The CDC "Flexible Processor" is a fully microprogrammed computer 
processor which has a highly flexible internal structure which permits 
its use in a wide variety of applications. Some of the specific charac- 
teristics of the main components of this processor are the following: 

(A) Microprogram Store 

The microprogram store consists of 1024 vords, 48 bits per word, 
125-ns cycle time. This is referred to as the processor’s "Large File." 
This memory is implemented with Schot tky TTL bipolar . tive element memory, 
with 256 bits/integrated circuit. Control of the "Large File" is by means 
of two generalized I/O busses, which can operate in parallel at z rate of 
one 16-bit word per 125-ns period; the 10-bit address to a word within the 
Large File is carried on one of these busses. 

(B) Register Files 

Four other register files are available as a resource to the execut- 
ing microprogram: 

1. The "Scratchpad File," consisting of up to 2048 words of up 
to 32 bits/word. This memory is also read/write, randomly 
addressible, and is implemented with bipolar TTL logic with 
a cycle time of 125 ns. 

2. The "Small File," consisting of 16 words, 32 bits/werd, 125 
ns cycle time for simultaneous read and write (to different 
words) . 
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TABLE 8 

SUMMARY' OF CHARACTERISTICS OF SPECIAL-PURPOSE HARDWARE 


Machine 

(1) CDC "Flexible 
Processor" 

(?) CHI AP-12C Signal 

Processor 

(3) General Dynamics 
High Speed D: r 

Architectural Type 

Mlcroprcgr enable 

Micioprogmr.c-.ablc 

IMpelinc Ptoccs^ct 

Basic Cycle Tire 

125 ns 

125 ns 

27 ns 

(KCL 10,000 Logic) 

Keoory System 

Control Store 

1024 » 48 b 0 125 ns 

1024 one 125 ns 

— 

Reglste. Store 

"8000 r 6 b capacity 

=6000 * 32 b capacity 

— 

Word Width 

16 b 

16/j? V 

16 

Processor Speeds 

Fixed Add 

125 ns 

125 ns 

27 ns 

Fixed Multiply 

250 ns 

350 ns 

27 ns* 

Floating Add 

J Software ( 

500 ns 


Floating Multiply 

j lnplct/ ntation( 

625 ns 


Input /Out put 

(a) circular buffer 
of 30 * 32 b ($ 125 ns 

(b) .'*2 b direct 
output 

(c) 4 JO ports 

Two 32 b <? 125 ns 
busses 

Buffer unit available 

Cost 

(‘’typical systcc”) 
Availability 

*$30K*" 

$60K 

$Not available* 

First Prototype 

Installed 

1972 

3rd quarter, 1973 

1972 

Delivery 

Negotiable; -12 mos 

4-6 oos 

18-24 nos* 


Assures saturated pipeline. 

i* 

Full configuration! In large quantities. 

*tiighly dependent on configuration. 
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The "Input File," consisting of 16 words, 32 bits/word, 125- 
ns cycle tine. This file has associated with it a 4-bit 
counter which can be used as a circular pointer within the 
input file. 

4. The "Output File," consisting of 1 word, 32 bits/word, 125- 

ns cycle tine. This "file" can be used for output of results 
simultaneously with computations and with input. For each of 
these files, both address and control information (whichever 
is appropriate) is transferred by means of the two data 
busses. 

(C) Processor Facilities 

Some of the specific features of the processor are the following: 

1. 8-bit by 8-bit multiply, implemented on one printed circuit 
card with hardwired static logic, operating in a total period 
of 250 ns. 

2. 16-bit by lo-bit adder, expandable to a 32-bit by 32-bit 
adder, which operates in a total cycle time of 125 ns in 
either case. 

3. 16 levels of interrupt, including appropriate masking 
capabilities. 

4. 5 condition registers, each 16 bits in length, with parallel 
masking registers of the same length. These registers are 
used to store the outcomes of previously completed operations, 
and, under mask control, can be used to alter the flow of 
microprogram control. 

5. A l6-wo»t ^-bits/word instruction pushdown stack. This 
stack can be used to implement very fast subroutine calling 
within the microprogram, or can be used to support recursive 
invocation of microprogram subroutines. 
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5. A flexible shift matrix, including l-to-8-bit and full-byte 

multiple shifts and exchanges of operands. This shift matrix 
width is the same as the width of the adder selected for the 
processor. [See" (2) above] 

7. Jour independent "input/uutput" ports which operate in a man- 
ner similar to that for a channel. These ports can be con- 
nected to other flexible processors or to a large memory exter- 
nal to the microprocessor (e.g. , the implemented processor's 
main memory) . 

8. The processor requires approximately 10 vertical inches in a 
standard 19-inch rack mounting system. Each four-layer 
printed circuit board measures 7.5 by 10.0 in. 

(2) Culler-Harrison, Inc.. AP-120 Signal Processor System 

The Culler-Harri~on, Inc. , AP-120 Signal Processor System is a fully 
microprogrammable processor with unique features and capabilities, parti- 
cularly in regard to internal processing speeds for floating poiut arith- 
metic. Some of the features of this system are the following: 

(A) Microprogram Memory 

The basic microprogram memory (writable control storage) consists 
of 1024 words, 32 bits/word, 125-ns cycle time; 512 words of this memory 
Is hardwired, and the remaining 512 words is dynamically changeable (see 
below). The microprogram control is of the "horizontal" type. 

(B) Registers 

Various • Lnds of machine accessible registers are provided, as 
follow : 

1. There are 16 index registers, 16 bits/word. These registers 
are used to store microprogram bate and relocation constants 
as well as microprogram inaex values. 
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2. There are 16 "scratch pad" general registers, 32 bits/registcr . 
These registers are used to contain intermediate floating 
point or fixed point computation values, 

3* There are 4096 words, 32 bits/word of KOS (Metal Oxide Semi- 
conductor) random access memory. This space is used as a 
dynamic swap area for segments of microcode used in the main 
microprogram memory and, in addition, can be used for data 
storage. 

4. There are 2048 words of 32-bit, hardwired read-only memory 

which are used to store various constants specific to the pro- 
cessor application. For example, the constants used in fast 
implementation (by table lookup and interpolation) of standard 
arithmetic functions (sin, cos, etc.) are stored in this 
region. 

(C) Processor Facilities 

The microprogrcmmable processor provides for both fixed point and 
floating point format arithmetic. The floating point format employs a 
24-bit fraction and an 8-bit exponent. The properties of the various 
functional units are the following: 

Fixed Multiply . A 16 bit by 16 bit fixed point multiply can be 
completed in three internal clock periods, or 375 ns. A 32-bit 
result is produced. 

Floating Multiply . A fully general 32 bit by 32 bit floating point 
multiply operation can be completed in five internal clock periods, 
or 625 ns. This time includes the time for operand renormalization. 

Fixed Add . A 16 bit by 1 bit fixed add operation can be completed 
in two internal clock periods. 

Floating Add . A general 32 bit by 32 bit floating point add opera- 
tion is completed in a total of four clock periods, or 500 ns. 
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Shift Matrix . The shift matrix can operate on 16-bit quantities, 
and can complete shifts of from 1 bit to 16 bits in one clock 
period (125 ns) each. 

i 

For all of these functional units it is important to appreciate 
that the overall execution time quoted is for the delay before which 
another operation of the same kind can be begun. Thus, overlap of all of 
these units is possible and highly parallel operation can result. 

(D) I/O Facilities 

Input/output between the microprograrcmable processor and its "host 11 
machine is performed on one cf two data buss systems! the I/O buss or 
the "host'* buss. Each buss is 32 bits wide and can process a complete 
32-bit operand once each 125 ns. Associated with the buss capabilities 
is a 32-bit accumulator which is also addressable from within the micro- 
programmed processor. 

(3) General Dynamics High-Speed Digital Processing Equipment 

The General Dynamics High Spead Digital Processing Equipment con- 
sists of a specially tailored pipeline processor, each pipeline stage of 
which can perform certain elementary operations on stands passed to it 
from its predecessor. In turn, each pipeline stage n deliver operands 

9 

to the successor pipeline stage. The initial and terminal pipeline stages 
are used to accept input operands and disgorge output operands; input and 
output eperana streams are assumed to originate from a "host" processor 
which has appropriate input/output data rates. 

General Dynamics current implementation technology permits each pipe- 
line stage to be as short as 27 ns, for an overall computation rate of 
37 * 10^ operations per second. For these operational speeds ECL 10,000 
logic is required; slower speed Schottky TTL-type logic permits stage 
times on the order of 50 ns. 
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Each special purpose pipeline processor must be specifically designed 
for its ultimate operational function. Individual stages are constructed 
with standard subcomponents, and individually programmed; the program is 
expressed as a collection* of permanent wiring performed under computer 
control by automatic wire-wrap equipment. A single processing stage (i.e., 
a single pipeline stage) can consist of one or more "boards**; the number 
of boards is dependent on the complexity of the particular processing 
function. 

(A) Standard Pipeline Components 

The General Dynamics development group has completed design of cer- 
tain relatively standard functional stages, among them: 

Adder Stage . The adder stage accepts two 16-bit fixed point operands 
in bit-parallel at each 27-ns (ECL 10,000 logic) interval; the 17- 
bit sum is delivered to the output register after a pipeline stage 
delay of 27 ns. 

Multiplier Stase . The multiplier stage accepts two 16— bit fixed 
point operands each 27-ns system period. The total delay through 
the multiplier stage is 10 system periods, or 270 ns, in the case 
of ECL 10,000 logic. 

Divider Stage . The divider stage accepts two 16-bit fixed point 
operands once each 27 ns (ECL 10,000 implementation); the total 
delay for this stnge is on the order of 350 ns. No exception pro- 
cessing (such as for a zero divisor, is performed in current imple- 
mentations although G!' bas indicated that such exception processing 
could be performed) . 

(B) Pipeline Organization 

There is no limit to the length of the processing chain, since each 
stage's operation is synchronized to arrival of data on its input regis- 
ters. The overall pipeline throughput is a function of the smallest of 
the individual pipeline stages' operand acceptance rates. Thus, for 
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example, a. pipeline constructed of adders, multipliers, and dividers such 
as those described above can operate on a new operand pair- at the 37-MHz 
rate indicated previously. 

■ 

(C) Special-Purpose Pipeline Stages 

For the EOS application, special purpose pipeline stages would 
have to be designed, checked out, and physically implemented. At the pre- 
sent time (and with present information on the GD system) it is not pos- 
sible to specify the exact nature of such designs. 

D Implementation Estimates 

In this section we provide preliminary characterizations of the man- 
ner in which each of the* three special purpose processors just described 
might be used in an off-loading role for EOS all-digital-image pro- 
cessing. In each case we make certain operational assumptions which 
allow concentration on the primary issue — estimation of overall process- 
ing tine saved; subsequent studies should address the validity of these 
assumptions in substantially greater detail. Specifically, we assume the 
folloT^ing: 

1. We assume that the special-purpose processor is supported by 
the "host” machine, a general-purpose processor, via its 
existing input/output structures. For example, this may 
occur via a "selector” channel or channels in such a way that 
data is streamed to and from the off-line processor at very 
high rates. 

2. We assume that the "host" machine processor participation in 
the control activities necessary to support the off-line 
operation requires at most 10% of the originally esti- 
mated processing load. Very likely, the actual figure would 
be considerably below this, particularly if optimum use is 
made of concurrent operation of host machine channels and 
processor. The figure of 10% is in keeping with our 
earlier mentioned threshold for efficacy of off-loading. 
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We assume that the host machine has sufficient primary and 
secondary memory resources to support enqueuing of relatively 
large amounts of "to be completed" all-digital image process- 
ing. This assumption is necessary because the efficiency 
attained by the special-purpose gear is highly dependent on 
the availability of data on a nearly continuous basis; in 
other words, we are assuming that it is possible to "keep the 
special purpose hardware busy" a substantial portion of the 
available processing time. 

(1) Radiometric Correction 

As mentioned earlier, the radiometric correction task can be assumed 
to operate on a table lookup basis since the correction table changes only 
slowly as a function of the position within the frame being processed. 
Implemented on a special purpose processor, this function requires two 
major steps: 

1. Periodic update of the "translation table" which specifies 
the radiometric corrections 

2. Streaming of the pixels to which the particular translation 
is to be applied through the special purpose processor 

Because of the relatively slow rate of table update, this function can be 

assumed to be performed within the usual 10% "overhead" allowance. 

We can now estimate the processing time for data streaming operations on 
each of the candidate special-purpose architectures. 

CPC Flexible Processor . Input and output of pixels can proceed at 
machine cycle rates — on the order of 3 * 10** pixels/s. Application 
of the (current) radiometric translation requires use of the pixel value 
as an index into the translation table, and placement of the indexed 
value on the output register; this operation can be performed in one 
machine cycle of 125 ns. Because input/output and internal processing 
can be performed concurrently, each pixel is processed at the rate cf 
8 * 10** pixels/s. 
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CHI, A?-i20 Signal Processor . This processor has two input/output 
busses which can operate concurrently with the microprogrannnable proces- 
sor. Hence, the computation can be organized in a manner similar to that 
for the CDC Flexible Processor, and can achieve the same rate: radiometric 

correction at 8 * 10^ pixels/s. 

GD High-Speed Digital Processing Equipment . In this special-purpose 
architecture it is possible to construct a special-purpose pipeline ,, stage n 
which stores the current value of the translation table in a 64 x 6 bit 
array; loading of this array to maintain currency of the translation table 
can be accomplished in a manner similar to that used to load constants 
into circular memories in the GD FFT implementations • If ECL 10,000 
logic is employed, each pixel can be translated at a rate of 27 ns per 
pixel, or for a total rate of 37 * 10 pixels/s. 

(2) Ground Control Point Correlation 

The ground control point (GCP) correlation computation can be charac- 
terized as consisting of an iterative series of sub-frame difference com- 
putations. A variety of techniques can be applied to the control of the 
selection of the "next point" within the search region, given the outcome 
of the correlation computation performed for the "previous point." The 
subopt imal estimation algorithm used in ref, 3 is descriptive of the num- 
Der of iterations likely to be required. 

Implementation of the GCP correlation computation on special-purpose 
gear can take ad% T antage of the fact that each iterative step involves 
essentially the same computations to be performed — only the reference 
point (which governs the pixel addressing) varies. One can suppose that 
there are two streams of data: (1) the reference point-based region within 

the search region, and (2) the ground truth information. The special pur- 
pose processor must compute the sum of the differences between each pixel 
pair. 
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CPC Flexible Processor . The circular input file within the CDC 
Flexible Processor can be used to accept data at a total rate of 250 ns 
per pixel pair (two streams). The single subtraction (the difference 
between the pixel pair values) and the accumulation of the sum of the 
magnitude of the differences can be accomplished with three microinstruc- 
tion executions. This sets the rate to one computation per three 125-ns 
cycles or 375 ns. Accumulation of the output is included in this process- 
ing time allowance (there are sufficient registers to contain this value). 
The stream rate is, therefore, 2.67 * 10^ pixels/s. 

CHI AP-1 20 Signal Processor . This processor can also support two 
input pixel streams, at a rate of 250 ns/pixel pair. As with the CDC 
machine, the absolute difference and summation operations can be accom- 
plished with three instructions per pixel pair; however, these can be 
overlapped at a rate of one initiation of the fixed add unit per machine 
cycle. The resulting computation is input/output limited (in the large) , 
at a rate of 250 ns/pixel pair. The stream rate is, therefore, 4 x 10^ 
pixels/s. 

GD High-Speed Digital Processing Equipment * For use of this special 
processor option in the GCP correlation computation a two-stage pipeline 
could be employed. The first stage would form the absolute difference 
between the two input pixels, and the second stage would accumulate the 
sum of the differences (the absolute correlation). Each stage could 
operate (with ECL 10,000 logic) at a rate of a new operand each 27 ns; 
the total throughput rate would therefore be 37 * 10^ pixel pairs/s. 

(3) Video Interpolation 

There are two primary means for performing the video interpolation: 

(1) the use of the "nearest neighbor" approximation, and (2) the use of 
cubic convolution. The latter is on the order of 20 times more resource 
consumptive than the former, and as a result it is suggested that algorithms 
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for performing this computation should be the subject of substantial 
further investigation. In either case, it can be assumed that the frame 
to which the correction transformation is to be performed is "gridded" 
into small regions within which no output pixel is shifted more than one 
pixel width. The identification of these grid regions is clearly per- 
formed best in the general purpose host computer. We treat the two 
primary algorithms for video interpolation separately. 

(A) Nearest Neighbor Algorithm 

This algorithm requires the identification of which pixel in a 
4-pixel grid is nearest to an interpolant point located within the 
4-pixel region. In effect, there are six data streams, as follows: 

1-4. The values of pixels at the four corners of the interpolation 
region 

5-6. The two coordinates of the interpolation point 

It can be assumed that the coordinate pairs of the interpolant point are 
given in floating point format; in this case, the nearest neighbor compu- 
tation can be considered as performed in the following fashion: 

Step 1: Add 0.5 x (distance between pixels) to each coordinate 

Step 2: Convert each value to an integer 

Step 3: Use resulting pair as selection address for nearest neigh- 

bor. The possible pairs are (0,0), (0,1), (1,0), and (1,1) 

Step 4: Transmit selected output pixel 

CPC Flexible Processor . Good use of the facilities provided by this 
machine suggest the following limiting factors: (1) the maximum input/ 

output rate is on the order of one pixel selection each 750 ns, and (2.) 
the processing time for each pixel is on the order of less than 750 ns 
per pixel selection. Thus, for this special purpose processor the compu- 
tation appears to be 1/0 limited at a rate of 1.34 * 10 pixcls/s. 
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CHI AP-120 Signal Processor . This special purpose processor has 
slightly less I/O capability than the CDC machine, and the slightly 
greater processing power does not compensate. It is estimated that the 
CHI AP-120 signal processor can perform the nearest neighbor computation 
at a rate of 1.0 x 10^ pixels/s. 

(8) Cubic Convolution Algorithm 

The cubic convolution algorithm, described briefly in sec. 3.2.1, requires 
the presence of four tables which store predetermined values from which the 
interpolant contributions for four pixels ar^ derived. It is estimated that 
each such table will require from 1024 to 4095 (i.e., between 2^ and 2^) 
entries; the total storage requirement is, therefore, between 4096 and 16384 
cells. This storage requirement is important because it eliminates one, and 
possibly two, of the alternative special-purpose hardware systems under in- 
vestigation. 

GD High-Speed Digital Processing Equipment . This implementation appears 
to be eliminated from consideration for the cubic convolution algorithm since 
it does not appear feasible to provide dynamically changeable memory within 
the processor pipeline which has enough capacity to store the four interpo- 
lation tables. 

CDC Flexible Processor . If the table sizes can be kept small enough 
to fit within the available 8000 byte capacity of this machine, then it is 
evident that the 1024 words of microprogram store would be more than enough 
to implement the cubic convolution algorithm. The overall processing rate 
would be set by the rate at which data can be moved through the machine and, 
since the cubic convolution algorithm requires only the sequential arrival 
of pixel values, the processor can operate at fu .1 rate. This rate is, 
therefore, set by the processor itself. The 38 instruction executions per 
pixel will require 4.75 ps. If the tables cannot be made to fit, it is 
important to note, then this alternative must be eliminated. The rate will 
be 0.21 x 10 pixels/s. 
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CHI, AP-120 Signal Processor . The tables required for the cubic 
convolution algorithm would easily fit into the 24,000 bytes (6000 words 
at 4 bytes per word) available on the AP-120. Again, the process would be 
instruction count limited, with an effective overall rate of 4.75 ps per 
pixel. The rate will be 0.21 x 10^ pixels/s. 
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(A) Summary of Implementation Estimates 

Table 9 summarizes the achievable processing rates for the three 
candidate special-purpose computer systems. There is only one further 
step necessary to validate the applicability of these systems: assuring 

that there is sufficient processing time available to support these 
special-purpose machines. 

It may be recalled t tat at least 123 s of elapsed time is available 
for the EOS computer complex to process each input frame (this figure 
was based on a total of 468 equivalent input HR i. frames per 16-hr 
processing day) . The slowest throughput for any of the special-purpose 
alternatives is 0.21 x 10^ pixels/s (i.e., cubic convolution function); 
hence, the longest any of the alternatives can tak-± to process a single 
frame is approximately 430 s, wnich is slightly under four times the 
length of the available processing window. This indicates that at least 
four parallel special-purpose processors will very likely be required 
for the worst case: cubic convolution interpolation. One can conclude, 

therefore, that the alternatives analyzed in the foregoing are viable, 
with the proviso already indicated in regard to maintenance of inter- 
pr cessor control, so long as special-purpose hardware is used in \ 
quadruple configuration for (at least) the cubic convolution computation. 

3.2.3 Input/Output (1/0) Units 

A Introduction 

This section is concerned with the development of an efficient 
and cost-effective I/O configuration for the central IPS facility. As 
no^ ;d before, the overall central IPS can be thought of as consisting 
of three major components — the preprocessor, processor, and postprocessor. 
Specifically this section focuses on the preprocessor and postprocessor. 
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TABLE 9 

SUMMARY OF ESTIMATE EXECUTION RATES FOR OFF-LOADED EOS FUNCTIONS 
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la addition, consideration is given to the devices used tc record 
the raw video data from tae satellite at the receiving stations. Since 
these video tapes must be compatible with the olayback equipment at the 
IPS, selection ot recorders must be optimal with respect to both sites. 

In addition, consideration is given to t\e recording devices used 
tc record the raw video data from the satellite at the receiving stations. 
Since these video tapes must be compatible with the playback equipment 
ct the IPS : optimum selection of recorders must be done considering 
both siter . 


In driving at a recommended configuration, future growtn of the 
system to meet possible increased future user demand was considered. 

In this regard a concept involving on-line archival product generation 
cot ,ned with off-line user product generation modules was considered. 

The following sections address in turn the receiving s^_ion and 
preprocessor configuration, the postprocessor configuration including 
archival formatting, available equipment, and a summary of the recom- 
mended configuration. 

B Receiving Station and Preprocessor 

Only the receiving facilities* digital recording devices were con- 
sidered within the scope this study. With regard to the digital re- 
cording devices used, the BOS spacecraft will transmit two multiplexed 
120 Mb/s signals (one from each sensor) to the receiving station, yield- 
ing a total information transfer rate of 240 Mb/s. This signal could 
then be recorded at the receiving station either at the 240 Mb/s rate 
by one recorder or demultiplexed and then recorded at 120 Mb/s by two 
rec* . u 3 . 
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In choosing between these alternatives on a purely economic basis, 
an approach using two 120 Mb/s recorders appears preferable* Though no 
firm figures are yet available, on the basis of information we have ob- 
tained, it appears that the cost of a 240 Mb/s machine is far more than 
twice that of a 120 Mb/s machine (see Appendix A). Furthermore, even if 
we assume that future technology can reduce the cost of a 240 Mb/s machine 
to only twice that of a 120 Mb/s machine (or perhaps even somewhat less 
than twice), there remains a requirement for a spare machine at a receiving 
station which we feel NASA should strongly insist upon* In this case, 
the 240 Mb/s machine would have to be the spare for a similar 240 Mb/s 
machine, whereas a configuration using two 120 Mb/s machines would require 
only one additional 120 Mb/s machine as a spare, representing a considerable 
cost saving. 

A second consideration is compatibility with the processor input 
recorder* Aside from this obvious requirement is the fact that the proc- 
essor input data rate is likely to be limited to the range of 7 Mb/s 
(sec. 3.2.1); thus whatever machines and recording format are used the> 
will need to be capable of a speed (or data rate) reduction of approxi- 
mately 20 to 1 (for a 120 Mb/s signal). Given the present state of 
technology, this almost certainly requires the use of multitrack linear 
recorders. Quad head and helical scan machines cannot at present achieve 
the high data rates required (120 Mb/s or 240 Mb/s) because they are one- 
channel machines and, with present high-density codes limited to 30 kb/in*/ 
track, enormously high head-to-tape speeds would be required; moreover, 
even if these high speeds could be achieved, the corresponding speed 
reductions required would be extremely difficult because of the require- 
ment to maintain a precise ratio between linear tape speed and head rota- 
tional speed. 

Accepting, therefore, the need for a multitrack linear recorder, 
note that one difference between a 120 and a 240 Mb's recorder would be 
that the latter would have twice the number of tracks. Now, since the 
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processor can handle only one sensor f s data at a time, only half the 
tracks on a 240 Mb/s recorder would be in use during each processing 
cycle, so there is no advantage in requiring the preprocessor recorder 
to be able to acconmodate and slow down a 240 Mb/s tape. Again, the 
cost o such a devic would be far in excess of that for one capable of 
handling the ^ormat required for a 120 Mb/s recorder. 

In summary, then, we believe that all receiving stations should be 
equipped with two 120 Mb/s recorders and one 120 Mb/s recorder as a spare. 

The preprocessing stage of a facility is meant to include only the 
input recorder to the processor and its controller. Again, the require- 
ments on this recorder are that it be capable of playing the tapes re- 
corded by the receiving facility; and since the maximum 1/3 rate of the 
processor is likely to be in the range of 7 Mb/s (sec. 3.2.1) and the 
tapes will have been recorded at 120 Mb/s, the input recorder must have 
a 20:1 slowdown capability. 

The recorder used here should be of the type used in the receiving 
station. Since, however, the transfer rate into the processor is limited 
to 7 Mb/s, it need not have the capability of recording or playing back 
at 120 Mb/s. Instead, as is common practice with multichannel linear 
recorders, it should have the same transport and head configuration, but 
with the electronics and, if such an option is available, the tape speed 
required for 7 Mb/s playbac\. 

C Postprocessor 

The postprocessing section includes all I/O equipment after the 
essor. 

The requirements on the postprocessing *»uipment are dictated by 
the products requirements as given in sec. 2.4. Briefly, these require- 
ments are: 
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(a) Two copies of all processed (2.7 x 10** bits) data on high- 
density digital tape for archival storage 

(b) Fvo copies of one band of each scene on 9.5-in. film 

(c) 20Z of all data (5.4 x 10^ bits) is to be recorded on high- 
density digital tape for shipment to users on request 

(d) Up to 50Z (1.35 x 10 11 bits) of all data would be processed 
outo film for user requests 

(e) 10Z of the basic scene load (2.7 x 10^ bits) would be 

recorded on computer-compatible tape for shipment to small 
users 

(f) Growth capability 

Growth capabil ity has been emphasized as a requirement, particularly 
for user products. NASA’s ERTS-1 experience showed some difficulty in 
meeting user demand as more applications of the information became known. 
For this reason system designs considered here do not require on-line 
production of user products. Instead these are produced off-line in 
modules that allow for increased dem*4.d by simply adding additional 
modules to the system. We fee 1 this modularity approach allows the 
necessary flexibility in meeting future user demands. 

The first consideration is what products, if any, should be pro- 
duced on line (that is directly from the computer) and what products 
should be produced off line from the master archival digital tape. 

Since two copies of high-density digital tape (HDDT) are required 
of all data along with two copies of one frame of each scene, one obvious 
configuration is that shown in fig. 11a for the on-line system. The re- 
maining products would be produced off line (fig. lib). 
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(a) ON LINE 



Figure 11. Candidate Postprocessor System A 










For the on-line system, since real time data is obtained, the film 
recorders and HDDRs must be dedicated to the processor for as long a time 
as is required to process the daily load. This is likely to be the full 
16 hours per day — and in any case no less than 10 hours, since the maximum 
data transfer rate is bound by the processor I/O rate of approximately 
7 Mb/s (see fig. 12). Thus the film recorders and HDDRs of the on-line 
system are effectively prevented from contributing in any way to the total 
off-line production capacity. 


Another factor is that the maximum processor I/O rate of 7 Mb/s 
is at least an order of magnitude slower than the transfer rates on avail- 
able film and magnetic tape recorders. In order to fully utilize the 
capabilities of present recording devices, the on-line/off-line config- 
urations as shown in figs. 13a and 13b are proposed. 


With these configurations all the data is first recorded on a master 
HDDT. This tape is then taken to an off-line facility where the speed up 
capabilities of a tape recorder can be used to record a second HDDT and 
the required copies of the film images; then the remaining requested 
images and tapes can be made. Since this system requires two less film 
recorders, this is obviously a desirable alternative if it can satisfy 
the product requirements. 


Candidate System A (fig. 11) 


The product requirements 

A Two copies HDDR 

B Two copies on film 

1 band each scene 

C 20% of all data HDDT 

D 50% of all data on film 

E 10% of all data on CCT 


and their bit loads are: 

2.7 x 10*^ bits/copy 

3.8 x 10^ bits/copy 
5.4 x io 10 bits 
1.35 x io 11 bits 
2.7 x io 10 bits 
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PRODUCTION TIME PER SENSOR (hr) 

Figure 12. Image Processor System: Processor-I/O Interaction 




OTHER PRODUCTS 


(b) OFF LINE 


Figure 13. Candidate Postprocessor System B 



81 






Requirements A and B are satisfied on line, and it is reasonable to 
assume that these require full utilization of the on-line equipment 16 
hours a day. Note that the transfer of the total data load, 2.7 • 10^ 
bits, at a transfer rate of 7.1 Mb/s (the maximum computer transfer rate 
we will assume) requires 10.5 hours. Utilizing the full 16 hours at this 
transfer rate permits the transfer of 4.08 * 10^ bits, or 2.0 times 
the basic daily load of 2 * 10^ bits from the satellite. ( However , this 
does not take into account the time required to mount the tapes, check 
out the processor, etc., all of which could require a considerable amount 
of time.) This would allow processing all the basic scene data using 
both cubic convolution and nearest neighbor interpolation with only 0.5 
MIPS additional processor burden imposed* It will be recalled that the 
present requirement calls for 30% of the basic data processed with nearest 
neighbor interpolation and 100% cubic convolution (sec. 2. 3. 1C). 

This leaves requirements C, I), and E. The time required to satisfy 
these is determined by the information transfer rate from the archival 
digital tape onto the required medium. Consider first computer-compatible 
tape since this represents the slowest transfer rate of any of the products. 
Standard computer tapes use packing densities of 800, 1600, or 6250 bytes 
per inch. Since 6250 BPI is not yet in wide use, it is advisable to 
consider only the lower speed ranges. The maximum transfer rates avail- 
able for 1600 BPI is 1.6 Mb/s for (8-bit bytes) or 0.8 Mb/s at 800 BPI. 
Figure 2 + illustrates the time problems of transferring data at this 
rate. NASA anticipates sending 10% of the daily load or 2.7 x 10^ bits 
of data to users on computer tape. This will require 4.18 hours at a 
minimum to prepare approximately 73 reels of computer tape 'at 2400 ft 
per reel). At 800 BPI, 9.37 hours will he required and 146 reels of 
tape. If these are not firm requirements, see the discussion later in 
this section for possible alternatives to CCT. 

The time required to transfer data to produce the films is a func- 
tion of both the maximum transfer rate and the formatting of the archival 
HDDT (either band sequential or pixel interleaved). 
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Figure 14. CCT Production Time 


8J 


If pixel interleaved is used [see (D) below for reasons for 
selecting it], producing a single frame requires playing through an 
entire scene; therefore, to obtain an estimate of the maximum time re- 
quired to transfer the data onto film, the time required to transfer the 
appropriate number of frames must be multiplied by 7 (the maximum number 
of frames per scene for tht hematic mapper). 

For meeting the film output requirements, EBRs have not been con- 
sidered since a 9.5-in. format cannot be achieved with any present EBR 
system, and in light of the vacuum requirements on EBRs such a format 
would not be practical. The transfer rate of LBRs is well in excess of 
100 Mb/s, and for all practical purposes, the limiting factor is the 
tape transfer rate. What maximum tape transfer rates will be available 
in the 1978 time frame is open to question; however, it is reasonable 
and convenient to assume a maximum of 120 Mb/s, thus using the same 
recorder for archival storage that is used in the receiving station and 
preprocessor. This would seem a desirable situation from both economic 
and reliability standpoints: the unit cost of each of the 120-Mb/s re- 

corder;' will decrease the greater the quantity ordered, and a minimum 
number of spare parts will be required. 

Assuming a 120 Mb/s transfer rate and a total of 1.35 * 10^^ bits 
to be transferred, the total transfer time (including a factor of 7 for 
pixel interleaving) is 2.2 hours. 

For calculation of the time required to produce the HDDT, assume 
a worst case situation where all users want band- interleaved data. The 
maximum transfer rate will depend on the device used for producing the 
HDDT for shipment to users. For production of user high-density tapes 
as opposed to archival high-density tapes — a primary consideration is 
the cost to the user for purchase of an appropri a playback device. 
These devices are fully considered in Appendix A, but for purposes of 
determining production capabilities, the slowest transfer rate of any of 
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the devices under consideration will be used. This rate is 7.1 Mb/s 
(which approximately corresponds to the maximum I/O rate of most computers) 

Under these circumstances, note that it is not necessary to include 
a factor of 7 in the time calculation. In extracting the data for a 
single band in a pixel-interleaved format, it is necessary only to block 

6 of the 7 bits output from the tape. Given this bl' eking device, the 
archival tape can be played into it at a rate of 49.7 Mb/s ( 1 * 7.1) 
while the output will be only 7.1 Mb/s of data into the recorder. Thus 
the total time required for transfer is 5.4 x 10^ b/7.1 x 10^ b/s, or 
2.1 hours. 

Note that in case of a 120 Mb/s transfer rate since the LBR is able 
to match the maximum transfer rite of the tape recorder, this factor of 

7 must be included. 

Thus, satisfying the total product requirement takes approximately 
13.6 heirs, leaving approximately 2.4 hours available for any growth 
potential. Note: These figures are very rough; uhey do not take into 

account time required to search for data or charge tapes, etc.; note, 
however, that all calculations have been for the worst case, which would 
tend to offset the overhead somewhat. 

Candidate System B (fig. 13) 

Since all production is off line, the times required would be as 
follows: 

(a) A second archival tape would be produced at a maximum data 
rate of 120 Mb/s, requi ring approximately 38 min. Note that 
both recorders would then be free for the production of 
additional products. 

(b) Using one recorder and 1 LBR, the time required to produce 

two copies of one band of each scene is approximately 8.75 hou 
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(c) Production of user HDDT, CCT, and user film requests would as 
for system A require 13.6 hours on one machine. Thus, out of 
a total of 32 machine-hours per day of production tine avail- 
able, 23.65 machine-hours (13.6 + 8.75 + 0.65 + J.65) are 
used, leaving 8.35 hours of free machine time. 

Thus system B, which uses three tape recorders and only one LBR, is 
a clear choice over system A, which uses three tape recorders and three 
LBRs. I.. general, maximum utilization of I/O devices is achieved when 
they are used off line to allow the highest data transfer rates. 

Other considerations affecting transfer crcabilities might be the 
use of two LBRs in system B as opposed to one. This would provide an 
additioral 4.4 hours of production time at the cost of cne LBR. This is 
an alternative to be considered if additional production time is needed. 

Perhaps the greatest increase in available production time can be 
had by the elimination of computer-compatible tapes. As shown at 806 BPI, 
nearly 10 hours of time are required to reproduce only 'u, of the data. 

As an alternative, we feel an ei coding/decoding device such as the Lockheed 
HD-103 should be used. Thio permits the encoding of a serial bit stream 
into a stream of parallel high-density tracks on a standard instrumenta- 
tion recorder. Using the Lockheed device as an example and a high-quality 
7-track instrumentation recorder, transfer rates of 20 Mb/s could easily 
be achieved with an enormous reduction in reproduction time from nearly 
10 hours to less than 1, thereby greatly increasing the capacity of the 
reproduction system. A full description of » ■ • devices available for 
this application is found in Appendix A. 

D Archival Formatting 

Another factor affecting the production time lines is the formatting 
scheme used on the archival tape 0 . Data can either be stored in pixel- 
interleaved or band-sequential format. The strongest case for band- 
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se juenti.il storage is that the largest part of the user-required data is 
the film (63%), and the production of films by the T BRs is facilitated 
if the data is in band-secmential format. (Since we ai currently 
considering monochrome reproductions, in a band-sequential format, only 
that portion of the tape containing the band of interest is fed the 

LBR at the maximum transfer rate available. If the data is in pixel- 
interleaved format, however, the entire scene, 7 fr r ^s, must be played 
back with the extra information blocked out.) 

However, there are several strong arguments against tie band-sequen- 
tial format. The prime one is that some users . crested in multisper tral 
analysis right want data in a pixel-interleaved format, which means pro- 
visions must be made for reformatting. Going from pixel-interleaved to 
band-sequential is relatively simple, if time-consuming, but the inverse 
is not the case. Going from band-sequential to pixel-interleaved requires 

a device with enough memory to store an entire scene and then rearrange 

9 

the bit stream. Since one scene contains approximately 2 x ]0 bits, 
either the central processor will have to be used, or if it is not avail- 
able (as will likely be the case) , much storage (multiple uisk packs) 
and a special processing T it will be required a. d would be costly. 

Another consideration is that, as users become more sophisticated, 
the requirements for pixel-interleaved data will increase, as thes users 
will be developing optical coding and sorting techniques. Moreover, the 
speed a- vantage of the band-sequential format will become less when the 
overhead times involved in loading and se <rchi n £; the tapes are fac ored 
iu. And again, as users become more sophisticated, the trend is likoly 
to be a call for tew r actual images and increased usage of digital tap^ 
for individual special process: 

For these reasons, we believe that archival data si ~>uld be stored 
in a pixel-interleaved format. 
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3.2.4 Summary of Recommended System Configuration 

Figure 15 and table 10 summarize our recommended configuration. 

The following two sections review the processor and I/O units separately. 

\ Processor Configuration Summary 

Our investigation indicates that processor configurations employing 

a single, large-scale, general-purpose computing system exclusively will 

* 

not handle the required computational loads. The possibility of off- 
loading functions that are performed in parallel by other special-purpose 
hardware must be considered in planning for the central facility. 

Off-loading such functions as radiometric correction, ground control 
point correlation, and cubic convolution interpolation (the greatest 
processing load contributor) to special-purpose processors currently 
available on the market was shown to reduce the overall computing require- 
ment of the central machine to approximately 6.3 MIPS, a substantial 
improvement. (This assumes off-loading removes 90% of the original com- 
putational burden for each function.) 

There still remains the problem of selecting the appropriate 
general-purpose computer system to support the EOS mission. In general, 
the analysis of a system for the purpose of providing a good basis for 
the selection of a basic general-purpose computer system entails an 
investigation of much greater detail than that possible here. This is 
true for many factors, not the least of which is the uncertainty associated 
with "rating" a computer system's performance. The problem is compounded 
by the fact that a certain portion of the machine resource is necessarily 
lost in support of management of the system' 3 storage facilities; this 
factor has not been addressed directly in the present study. It is evi- 
dent that substantial further investigation will be necessary before a 

a 

The possibility of using two or more parallel general-purpose machines 
was excluded because of excessive cost (likely to exceed $15M for the 
processors only) . There are also disadvantages related to added process- 
ing overhead, data transfer, etc. 
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Figure 15. Recommended Configuration - Central Facility 
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final machine selection can be made; such a study would address specific 
configuration questions pertaining to memory and peripheral organizations 
as well as the central issue of basic machine processor performance. 

It is possible, however, to provide a preliminary Indication of the 
range of computer systems which, within the limitations of information 
known at the present, appear to be suited to this application. These 
particular machines are mentioned because of the clearly indicated need 
for substantial machine computing resource, as well as the corresponding 
need for substantial amounts of memory and peripheral storage capability. 

Typical machines which have the capability to operate in the 6.5 MIPS 
range or greater include 

IBM 360/195, which has a capability on the order of 12-14 MIPS 

IBM 370/168, which, with appropriate complements of memory, 
can operate in the range of 5-10 MIPS 

IBM 370/158, which can operate in the 3-8 MIPS range 

CDC 7600, which has a capability in the range of 10-15 MIPS 


Cost estimates for machines in this capability range can only be 
made in conjunction with a detailed configuration study. In spite of 
this, however, our experience with large-scale systems suggests the 
following guidelines for computer systems of particular MIPS capabilities: 


2- 3 MIPS: 

3- 5 MIPS: 

4- 6 MIPS: 
6-15 MIPS: 


$1-2 x 10 6 
$2-3 x 10 6 
$3-4 x 10 6 
$6-8 x 10 6 


The actual cost for a general-purpose computer system depends on the 
particular memory components selected, the input/output channels used, 
and the complement of peripheral storage. 
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Special-purpose hardware costs are a relatively small fraction of 
the general-purpose system costs; typical special-purpose equipment is 
estimated to cost approximately $100K per processor (fully equipped with 
appropriate interfaces, etc.)* Assuming that at least five special- 
purpose processor units like the CDC Flexible Processor or Chi, AP-120 
Signal Processor (table 9) will be required (i.e., four for cubic convo- 
lution, and one for the remainder of the off-loaded functions) total 
processor hardware costs are estimated between $7M and $8M. 

B I/O Summary 

Figure 15 expands on the conception shown in fig. 13; the appro- 
priate controllers have been added. (Table 10 summarizes the I/O unit 
quantities and cost estimates.) The same tape transport is used through- 
out with equalizing electronics for the appropriate transfer rates. For 
recorders A and B, the transfer rate need only be 8 Mb/s. For C and D 
the maximum transfer rates available (compatible with the LBR) are 
required. This is likely tc be 120 Mb/s, since this race if required in 
the receiving station recorders, and unless higher rates can be obtained 
with minimal investment, there is no compelling reason to spend any R&D 
funds to obtain them. A quick-look device, either a CRT or an already 
existing EBR or LBR, is provided for use on the on-line system to 
determine any malfunctions. A provision is made for both computer- 
compatible tape and an encoder scheme, with the latter the recommended 
approach. Specific devices for use in this configuration including their 
performance characteristics, costs, and limitations, are discussed in 
appendix A. 

The exact cost will, of course, be a function of the specific 
devices selected for use, but table 10 represents our best estimate of 
what the costs should be based on our discussions with potential suppliers 
of I/O equipment. Note that although the system will be operational in 
the 1977-78 time frame, cost estimates are made in 1973 dollars. 
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3.3 REGIONAL FACILITY CONFIGURATION 

This section discusses our recommended point design for the regional 
processing facility. Recall that this facility is meant to be a scaled- 
down version of the central facility intended for image processing and 
product generation for the needs of a given region only. These facilities 
might , for example, be located in, and operated by, various state authori- 
ties throughout the U.S. to serve users interested in monitoring state or 
local resources and phenomena only. For purposes of this study, this 
facility is assumed to meet the same general requirements regarding work 
week, processing functions performed, etc., as the central facility but 
differs in its capability of handling only 30% of the central facility 
scene load and product generation. 

Figure 16 and table 11 summarize our recommended configuration. The 
following two sections review the processor (Including MIPS estimate) and 
I/O units separately. 

3.3.1 Processor Configuration 

The regional facility must perform the same computations as the 
central site, but need make them only for a portion of the total available 
EOS Imagery. Table 12 shows the total MIPS requirement for a 30% scene 
load. The total MIPS count is, of course, based upon the same availability 
(16 hours per day to process 30% of the scene load), and general procedure 
and assumptions outlined in sec. 3. 2.1. A. 

Because processor size is set by the largest frame to be processed, 
the machine chosen for the regional facility must have the same memory 
capacity, but can safely have as little as -7 MIPS processing capacity. 
Because this is a capacity requirement which can be filled only by large- 
scale computers (table 7), the possibility for off-loading functions should 
be applied in planning for this facility also. This is based on the 
following cost-effectiveness considerations. 
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Figure 16 . Regional Facility Configuration 


















TABLE 11 

SUMMARY OF RECOMMENDED REGIONAL FACILITY CONFIGURATION 
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TABLE 12 
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Subtotal 3.55 3.57 







Assuming as before (sec. 3. 2. 2. A) that special-purpose processors 
can remove up to 90% of the original computational burden, and assuming 
that only cubic convolution interpolation is offloaded, the total MIPS 
estimate (table 12) can be reduced to the order of 2.0 MIPS. Next recall 
from table 9 that the slowest cubic convolution execution time for any 
of the special -purpose alternatives is 0.21 * 10 pixel/s. Hence, 
approximately 430 s are required to interpolate (cubic convolution) a 
single HRPI frame (-90 x 10** pixels); and since approximately 394 s of 
elapsed time is available (based on a total of 146 equivalent HRPI frame 
input per 16-hour processing day) at most two parallel special-purpose 
processors would be required. 

Considering the general-purpose and special-purpose processor costs 
outlined in sec. 3.2.4, a configuration employing a 2.0-MIPS general- 
purpose machine with two special-purpose processors would run in the $1 
million to $2 million range. On the other hand, a 7-MIPS machine 
(general-purpose only configuration) would run in the $6 million to $8 
million range. 

Clearly, based on these cost considerations, the possibility of 
offloading functions to special-purpose hardware should be considered 
in planning for the regional facility as well. 

3.3.2 1/0 Configuration 

In selecting an optimum configuration for the regional facility, 
there are two primary considerations. The first is, of course, the 
reduced data load (30% of the central processing facility) . The second 
is the requirement of compatibility between the central facility output 
and the regional facility output. 

Examining the first with regard to possibly reducing 1/0 costs for 
regional facility, consider the I/O equipment breakdown for the central 
processing facility: 
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4 high-speed recorders $40 r ■ 

1 laser beam recorder 'J,000 

1 cassette unit 15,000 

1 encoder li,000 

1 CCT unit 

and appropriate controllers 

Not including spares. 

Since the regional facility must produce the same type of output 
as the central facility, the LBR, cassette unit, encoder, and CCT unit 
must be pro' ‘ded with appropriate controllers, thus eliminating these 
areas as cost reduction possibilities. 

The only remaining area where costs could be reduced would involve 
a reconfiguration of the system to either require fewer high-speed 
recorders or less expensive recorders. Compatibility between the regional 
and the central facility now becomes an important consideration. The 
input recorder to the processor must be able to reproduce the tapes 
recorded at the receiving station, therefore, it must be the same tape 
as is used at the central facility. With regard to the three remaining 
recorders, it must be assumed that for max^jum cost savings the processor 
will be scaled so that it will have just enough capability (with a safety 
margin, of course) to cope with the daily data load. Therefore, the 
second recorder will be tied to the processor during most the day. If 
there is now a requirement to produce a second digital copy of the data 
plus two copies of one frame from each scene ptocessed, then recorders 
with a speed-up capability will also be required. However, because of 
the reduced data load, only one off-line recorder is required. 

The recommended configuration is then as shown in fig. 15. Where 
a duplicate digital tape is made from recorder B to recorder C at a high 
data transfer rate (120 Mb/t as before) and using 30% of data loading 


98 



and produce requirements of the central facility, the total time required 
for processing is 6.99 hours, leaving 9.1 hours of free machine time for 
future expansion. 

It should also be noted that, even if the data requirements are not 
exactly the same as for the central facility, this configuration provides 
the maximum flexibility and expansion potential. Also, by using the 
same equipment as the central facility, archival tapes produced at either 
facility can be interchanged to compare processing schemes. 

The total cost for I/O equipment (table 11) for the region facility 
is, therefore, the same as for the central facility less the cost of one 
recorder. 
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APPENDIX A - 

IMAGE AND DIGITAL RECORDERS 
A. 1 PREPROCESSING AND RECEIV7 \ STATION RECORDERS 

• REQUIREMENTS 

(a) Either one device capable of recording 240 Mb/s or two 
recorders capable of recording 120 Mb/s each. 

(b) Capability of slowdown to at least 8 Mb/s . 

• AVAILABILITY 

At present, only two firms are involved in production of recorders 
approaching the data rates required for EOS. Ampex has built and shipped 
to TRW a multitrack recorder capable of 80 Mb/s data rate. RCA believs 
it has the capability to construct a recorder with up to a 240 Mo/s 
data rate. 


• SPECIFICATIONS FOR THE AMPEX 
Transfer rate 

Error rate 

Tape 

Tracks 

Packing density 
Tape speed 
Slowdown capability 
Cose 


RECORDER 

80 Mb/e 

1 in 10^ guaranteed, 1 in 
10® demonstrated 

1-in standard tape 

25 tracks data 
3 track housekeeping 

20 kb /in/ track 

150 ips 

100 to 1 

approximately $100,000 
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TECHNOLOGY LIMITS 


(a) Present recording codes limited to 30 kb/track density 

(b) However, high input rates may be achieved by using one or 
both of the following methods: 

• Increasing tape speed resulcs in increased input data 
rate. However, this also results in less recording 
time — at 150 ips, a 10,500— ft ree^ lasts only 14 minutes 
transmitting 2 x 10 in. bits at 240 Mb/s requires 
13.88 minutes. 

• Increased tape width (from 1 in to 2 in on the Ampex) 
could accommodate the additional channels required 

to obtain 240 Mb/s input rate if only one recorder 
is desired. This, however, results in deskewing problems 
due to tape deformation. 

A. 2 DIGITAL PRODUCTS 

The digital products required are HDDTs for archival storage, HDDT 
user products and CCT user products. The requirements and specifications 
of recorders now available to produce the archival HDDTs are sum- 
marized in Table A-l. The Ampex unit is recoimnended since its speed-up 
capability allows the most flexibility in the off-line production system. 

GRC has also investigated various possibilities related to recorders 
for purchase by the EOS users. Minimal cost and a standardized high-density 
digital output product were considered as criteria. The recommendation 
here is an 1VC cartridge high-density recorder fully compatible with and 
having the same specifications as the IVC-MMR due to be available in 
1974 (table A-l). With a cartridge capacity of approximately 2.5 x 10^ 
bits, it would represent an ideal recorder for the users to purchase and 
for NASA to use in making digital products. However, the 6 Mb/s through- 
put rate might be too high for use in the data processing facilities of 


102 



some smaller users, and none of the IVC machines has the capability of 
speed reduction- As an alternative we suggest the Lockheed HD-103 
serial-to-parallel converter, specifications for which are listed in 
table A-2. This can be used with any high-quality instrument recorder 
with a 2-MHz bandwidth. If a single 7-channel HD-103 is used to record 
12 channels (6 at a time) on a standard 14-track instrumental recorder, 
this will yield approximately 250 kb in packing density. Use of the 
HD-103 would allow the reduction of output rate in proportion to the 
speed reduction capabilities of the recorder (i.e., if the recorder allows 
a 10 * speed reduction, throughput rate can be reducted from 6.3 to 
0.63 Mb/s). Since most small users probably possess a high-quality 
recoider, this alternative represents a relatively modest investment. 

We feel that the use of the HD-103 is preferable to the use of computer- 
compatible tape. 

For the production of CCTs a variety of recorders are available at 
recording densities of 556,800 and 1600 BPI at a relatively low price. 

Due to the relatively low transfer rates required, however, producing 
CCTs will be extremely time consuming. As an alternative we would 
recommend the Lockheed HD- 103 again as a low-cost high-speed alternative. 
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TABLE A-l 

OUTPUT DEVICES - HIGH DENSITY DIGITAL TAPES 


• Requirements 

• Ability to handle computer output rate 

• Two digital tapes of all data are required for archival 
purposes 

• Availability 

• If the computer is limited to thruput data rates in the 
order of 8 megabits/sec, then either the IVC-MMR or RCA 
TR-70 recorders could be used 

• If pipeline processors or special purpose equipment permit 
significantly higher data rates, then an Ampex or RCA 
recorder such as used on the input side should be considered 

• In our recommended configuration a recorder with a substantial 
speed change capability is required, and given the present 
state of technology, only linear nulti track recorders can fill 
these requirments 

• Data is provided on the IVC and RCA recorders in the event 
NASA desides on another configuration for the processing 
facility 

• Data on the Ampex recorder is provided in the previous section 

Specifications: IVC-MMR 

• Signal Electronics Data (Rotating Head) 

Input /Output 8.1 x 10^ bits/sec 

6 2 

Packing Density 1 x 10 bits /inch 

Throughput 7 x 10** bits/sec 

Error Rate < 1 in 10 (uncorrected) 

Input Data Format Serial NR2 plus clock 

Output Data Format Serial NRZ plus clock 

Addressable Record 119 bits 

Capacity on 7000’ Reel 8.5 x 10^^ bits 

Cost $50,000 
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TABLE A-l (continued) 

OUTPUT DEVICES - HIGH DENSITY DIGITAL TAPES 




Specifications: RCA TR-70 

2 2 

Packing Density 400 kb/in or 800 kb/in 

7 

Error Rate 1 in 10 ‘ with 400 kb packing density 

1 in IQ 6 with 800 kb packing density 

Input Rate 15 Mb/s 

Output Rate 15, 7.5, 3.75 Mb/s 

Tape Size 2 in standard videotape 

Cost $150,000 

IVC Cassette unit 

• The IVC cassette has the same specifications as the MMR with 
the exceptions of 

(1) no search speed capability 

(2) smaller reel size (2500 fO 

(3) cost of approximately $15, 0w 

• IVC anticipates production of the cassette unit in early 
1974. 
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TABLE A-2 

COMPUTER-COMPATIBLE OUTPUT (HD-103) 


Number of channels 
Input rate 

Output rate 
Packing density 

Error rate 

Recorder requirements 
• Cost: $16,000 


7 

Variable (approximately 100 to) 
to maximum of 21 Mb/s (depending 
on the quality of recorder in 
use) 

Variable (as above) 

Maximum 231 kb/in. (7 tracks— 
dependent on quality of recorder) 

1 in 10 6 

For maximum performance 2-MHz 
bandwidth recorder is required 
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A. 3 FILM RECORDERS 


As with the tape recorders, no device is commercially available 
that is perfectly suitable for EOS use. The closest is the RCA PAR-5 
LBR which satisfies all of the technical requirements for the EOS system. 
Basically, these requirements are as follows: 

• a 9. 5- in film format 

• resolution adequate to reproduce 6300 elements over approx- 

imately 7.5 in 

• at least 128 intensity levels 

• hands -off operation 


Below are some specifications for the RCA PAR-5 and other LBRs 
that might be considered: 



PAR 5 

Laser Beam 
Image 

Reproducer 

(LBIR) 

Wideband 

Signal 

Recorder 

LR 70 
Series 

Bandwidth 

100 MHz 

25 MHz 

200 MHz 

75 MHz 

Resolution 

120 lp/mm 
@0.5 MTF 

80 lp/mm 

120 lp/mm 
@0.5 MTF 

100 lp/mm 
@0.5 MTF 

Signal-to- 
Noise Ratio 
(pp/rms) 

20 dB 

20 dB 

30 dB 

30 dB 

Amplitude 

Linearity 

1Z 

1% 

5% 

5% 

Scan 

Linearity 

0.1% 

0 . 1 % 

6% (off 

axis 

scanner 

0.1% 

Scan Jitter 

<2 ym (rms) 
<1 ns (rms) 

9 ym; 

30 ns (rms) 

<0.4 ym; 
0.3 ns (rms) 

0.5 um; 

1 ns (rms) 

Transport 

Periodic 

Erros 

2 ym (rms) 

1 ym (rms) 

2 ym (pp) 
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CBS has met each of the above requirements in various LBR systems, 
but no one system integrates all of these requirements. 

A system now being prepared for delivery uses a 17 in. * 22 in. 
flat field format. While the resolution is adequate for the TM, it does 
not satisfy HRPI requirements. Further, the data rate is limited to 
approximately 2 MHz. 

The peculiarity of this system is that it uses a mirror mounted 
on a galvanometer rather than a multifaceted spinning mirror. The ad- 
vantage of the galvanometer approach is that it may cost less than a 
tenth that of the spinning mirror assembly. The disadvantages are that 
it limits resolution and data rate. 

The CBS-built JIF DATS system has more than adequate resolution 
for both the TM and the HRPI and data rates, about 20 Mb/s. The format 
is only 5 in, however. 

With regard to hands-off operation; CBS was skeptical of the use 
of continuously moving film in an LBR because of the skewing and deforma- 
tion problems. An approach CBS considered using is advancing the entire 
table. This is the approach being used in the first system described 
here. 


In table A-3, specifications are given for the CBS JIF DATS system. 

Costs - RCA has indicated that a version of the PAR-s with non 
military specifications could be constructed for approximately $150,000. 

CBS was very vague about costs, i.e., 100K < cost < 1 million, for 
model 1. Beyond that, CBS believed costs might be reduced to $75 thousand 
to $100 thousand per model if the galvanometer approach can be used — 

$40 thousand to $50 thousand greater than that if a spinning mirror 
is required. 
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TABLE A-3 

CBS JIF DATS LBR SPECIFICATIONS 


Components 
Video Bandwidth 

Resolution 


Film Advance Rate 

Modulation Transfer 
Function (MTF) 

Film Capacity 

Film Width 

Output Imagery 

Distortion (Geometric 
Linearity) 


In-Flight Photo Processor-Scanner (IPPS) 
Ground Recorder-Processor-Viewer (PRPV) 

High Resolution - 18.9 MHz 
Med. Resolution - 12.6 MHz 
Low Resolution - 6.3 MHz 

High Resolution - 60 lp/mm 
Med. Resolution - 35 lp/mm 
Low Resolution - 20 lp/mm 

High Resolution - 0.557 ips 
Med. Resolution - 0.956 ips 
Low Resolution - 1.67 ips 

Exceed 0.1 in High Resolution Mode 
Exceed 0.4 in other modes 


IPPS: 350 ft - thin base 

PRPV: 1000 ft - thin base 

5 in - unperforated 


±0.15? 
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